T09 · Insecure Skill Coding Practices
- Location
references/examples.md:115- Finding
Profile Sanitization Uses a Bypassable Field Denylist
- Content
View full analysis
): UserProfile { const safe: Record = {}; for (const [key, value] of Object.entries(profile)) { if (!BLOCKED_FIELDS.has(key.toLowerCase())) { safe[key] = value; } } return safe as UserProfile; } ``` ### Technical Analysis The examples accept an arbitrary profile dictionary and remove only fields whose top-level names exactly match a limited denylist. A denylist cannot reliably identify all possible names or structures containing sensitive information. For example, fields named `mobile`, `contact`, `access_token`, `card_number`, or `shipping_contact` are not blocked. Sensitive values nested inside an otherwise permitted object are also not inspected. The TypeScript type assertion does not provide runtime validation and therefore does not restrict the actual keys or value types transmitted. This implementation conflicts with the Skill's stated guarantee that phone numbers, email addresses, identity information, payment information, passwords, and tokens must never be transmitted. ### Attack Path 1. A user, integration, or prior Agent operation constructs a `user_profile` object. 2. Sensitive data is placed under an unlisted alias or nested structure, such as `{"contact": {"mobile": "..."}}`. 3. ...[truncated 854 chars]- Remediation
View remediation
