access-control

Access Control Detection

Overview

Access control decides whether an already-identified caller may perform an action or reach a resource. It fails when that decision is skipped, made from data the caller controls, enforced in one layer but not another, or applied to some steps of a flow and not others. The attacker is usually an authenticated low-privilege user (sometimes anonymous) who changes an identifier, a role value, a header, an HTTP method, or the order of steps to reach another user's data (horizontal), a privileged function (vertical), or a state they should not be in (context-dependent). This skill finds such gaps by locating every site where authorization should be enforced, verifying each one in parallel, and merging the results into <output_dir>/access-control-results.md.

What it is NOT

• Missing authentication (/websec:authentication): the endpoint requires no login at all. Test: if adding a valid session changes nothing about who may reach it, it is an authentication problem. Here the caller is authenticated (or the resource is reachable) and the authorization decision is missing or wrong. How the identity was obtained is likewise not this class — a delegated grant is /websec:oauth, a signature or a claim minted from a user-writable field is /websec:jwt; here the identity is taken as given and only what it may reach is in question.
• Information disclosure (/websec:information-disclosure): the application volunteers data (verbose errors, backups, debug pages). Here the attacker pulls data through a missing check. A ?user= parameter that returns another user's record is access control when an ownership check is the missing control.
• Business logic (/websec:business-logic): tampering with price, quantity, or discount is logic abuse unless it crosses an ownership or privilege boundary. Changing role=admin or owner_id in a bulk-bound body is mass assignment — classify it here only if the changed field grants access; otherwise note it under "Also observed" for /websec:api.
• Injection via an id field (/websec:sql-injection, /websec:nosql-injection): ?id=1 OR 1=1, or an id that arrives as an operator object and changes the filter document's shape, is injection, not authorization.
• Not a finding: an authorization decision that architecture.md records as made outside this tree — a gateway, reverse proxy, service mesh, or shared library that maps callers to scopes before the request arrives. Read the "Enforced where" column and the trust-boundary section before recording an absence; a service whose handlers carry no guard because an external layer decides is not a page of findings. Judge that configuration where it is readable; where it is not, the label is NEEDS MANUAL REVIEW naming the file a human must open. What is judged here: whether this service would believe a caller who reached it directly, bypassing that layer, and whether it trusts a role, tenant, or identity value the layer supplies without any check of its own.
• Not a finding: a resource that is intentionally public (posts, product pages); an unguessable reference that the server also checks ownership on; a role check enforced server-side even though the UI merely hides the link; scoping done by the framework in the guaranteed form (current_user.orders.find(id)).