T05 · Unauthorized Access and Privilege Escalation
- Location
references/validation.md:7- Finding
Client-Controlled Administrative Role Enables Privilege Escalation
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is a coherent backend API coding guide with no hidden execution, but it contains security-sensitive examples that could lead agents to generate insecure user and list endpoints.
Review this skill before installing if you expect agents to generate security-sensitive backend code. It is not showing hidden execution or exfiltration, but users should correct the user-creation validation pattern so public clients cannot set roles or activation state, and should add bounded query validation before relying on the route templates.
references/validation.md:7Client-Controlled Administrative Role Enables Privilege Escalation
assets/templates/feature.route.ts:18Unvalidated and Unbounded Pagination Input Reaches Database Queries
Referenced artifact was not completely inspected
See `references/utilities.md` for helper functions:
Referenced artifact was not completely inspected
See `references/utilities.md` for helper functions:
Referenced artifact was not completely inspected
- See `references/senior-engineer-mindset.md` — **READ THIS FIRST** — Thinking patterns, API design, security, performance, code quality standards
Referenced artifact was not completely inspected
- See `references/senior-engineer-mindset.md` — **READ THIS FIRST** — Thinking patterns, API design, security, performance, code quality standards
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
✅ GET /users/:id → get one
✅ PUT /users/:id → replace
✅ PATCH /users/:id → partial update
✅ DELETE /users/:id → delete
❌ GET /getUsers
❌ POST /createUser
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
❌ GET /getUsers ❌ POST /createUser ❌ GET /user/list ❌ DELETE /deleteUser/:id
### Nested Resources — Only When Necessary
The manifest description says to use the skill when 'building new REST APIs, implementing features, fixing bugs, or refactoring backend code,' which covers a very wide range of ordinary development activity without clear boundaries. It does not provide specific trigger phrases, exclusions, or negative examples to distinguish when this skill should activate versus other coding skills.
The documented AppError class at L260-L267 only defines a code and message, but the error handler at L292-L299 uses err.httpStatus to set the HTTP response status. This is not just incomplete documentation: the shown implementation would produce an undefined status unless AppError carries httpStatus elsewhere, contradicting the claim that these snippets represent the standardized error-handling pattern.
Skill allows unbounded resource consumption (API calls, storage, compute). Without rate limits or quotas, a compromised or misbehaving agent can cause denial-of-service or cost overruns.
❌ `console.log` left in production code
❌ Empty catch blocks that swallow errors
❌ Hardcoded secrets/credentials in code
❌ Unbounded queries (no pagination, no limit)
❌ `any` type everywhere — type everything explicitly
❌ `await` in a loop when Promise.all works
❌ Return raw Prisma entities from services (always map to DTO)
At L113 the controller comment states the service returns 'AppError or data', matching the pattern described at L136-L138. But the findAll example at L124-L129 destructures { data, meta } from the service result and then checks whether data is an AppError, which contradicts the stated contract because AppError would be the whole return value, not nested inside data.