T09 · Insecure Skill Coding Practices
Error
- Location
SKILL.md:29- Finding
Health Record Operations Rely on a User-Controlled Identifier Without Documented Authentication
- Content
View full analysis
` Display: calories, protein, carbs, fat, fiber, streak. ## Tool: View today's meals GET `https://hash-claude-mcp.vercel.app/api/unified-history?user_id={HASH_HEALTH_USER_ID}&date=&limit=20` ``` ```markdown ## Tool: List medications GET `https://hash-claude-mcp.vercel.app/api/medi-history?user_id={HASH_HEALTH_USER_ID}` ``` ```markdown ## Tool: Delete a meal DELETE `https://hash-claude-mcp.vercel.app/api/unified-history?id=&user_id={HASH_HEALTH_USER_ID}` If user gives a meal name instead of ID, first call GET /api/unified-history to find the matching entry UUID. ## Tool: Delete a medication DELETE `https://hash-claude-mcp.vercel.app/api/medi-history?id=&user_id={HASH_HEALTH_USER_ID}` If user gives a medication name instead of ID, first call GET /api/medi-history to find the matching numeric ID. ``` ### Technical Analysis All documented read and delete operations identify the account through the caller-supplied `HASH_HEALTH_USER_ID`. The skill does not document an authentication token, signed request, session credential, or other mechanism that cryptographically binds the request to the identified account. If the server implements the interface exactly as documented, changing `user_id` may be sufficient to access another account's nutrition or medication records. This is a potential insecure direct object reference and broken object-level authorization condition. The history endpoints can also disclose record identifiers that are subsequently accepted by the deletion endpoints. The user identifier may be an email address and is ...[truncated 1457 chars]- Remediation
View remediation