Detects missing ownership checks, broken role enforcement, and IDOR vulnerabilities that let users access other users' resources. Use when writing code that checks authorization, enforces resource ownership, handles IDOR (object-level authorization), processes server-side requests to external URLs, or implements access control middleware.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Detects missing ownership checks, broken role enforcement, and IDOR vulnerabilities that let users access other users' resources. Use when writing code that checks authorization, enforces resource ownership, handles IDOR (object-level authorization), processes server-side requests to external URLs, or implements access control middleware.
Broken Access Control Security Check (A01:2025)
What this checks
Protects against unauthorized resource access caused by missing ownership checks or
role enforcement. Exploitation leads to horizontal/vertical privilege escalation.
For SSRF (server-side request forgery), see the dedicated ssrf skill.
Vulnerable patterns
Resource lookup by caller-supplied identifier with no ownership predicate before the row is returned, mutated, or acted on
Privileged or admin route mounted with no role check at the route/controller declaration
Ownership check that runs after the resource has already been fetched and consumed by downstream logic
Ownership failure that responds with a distinct "forbidden" status, leaking that the resource exists
Fix immediately
Flag the vulnerable code and explain the risk. Then suggest a fix that establishes
these properties:
Every resource lookup by caller-supplied identifier is gated before the resource
is returned, mutated, or acted on. The gate binds the row to the authenticated
caller — an ownership predicate for per-instance access, or a role predicate for
role-scoped access. The check can live in a handler, interceptor, filter, annotation,
decorator, or middleware — anywhere, as long as it runs before the data is used.
Privileged routes enforce role membership through a reusable, centrally-declared
mechanism (middleware, filter chain, annotation, decorator, policy) attached at
the route or controller declaration. Ad-hoc if role != "admin" checks inside
handler bodies are brittle — they can be forgotten on a new route and they're
invisible at a glance.
Ownership failures return an indistinguishable "not found" response (HTTP 404).
Returning 403 leaks that the resource exists. Role-missing failures on a privileged
route may still return 403 — the route itself is public knowledge, so only the
instance-level check needs to hide behind 404.
Translate these principles to the audited file's language and framework. Use the
documented authorization or policy mechanism for that stack; do not invent ad-hoc
checks in handler bodies.
Verification
Confirm these properties hold (language-agnostic):
Every resource lookup by caller-supplied identifier is gated by an ownership or role predicate before the resource is returned, mutated, or acted on — regardless of whether the check lives in a handler, interceptor, filter, annotation, decorator, or middleware
Privileged routes enforce role membership through a reusable, centrally-declared mechanism (middleware, filter chain, annotation, decorator, policy) attached at the route/controller declaration — not via ad-hoc if checks inside individual handler bodies
Ownership (per-instance IDOR) failures return an indistinguishable "not found" response (e.g. HTTP 404) rather than a distinct "forbidden" response, to prevent resource enumeration. Role-missing failures on a privileged route may use 403 because the route itself is public knowledge
