Why scanners miss access control

What does the flaw look like?

An endpoint returns an invoice, a patient record, a document, a booking. The application checks that the caller is logged in. It does not check that this particular record belongs to them. Change the identifier in the request from 1041 to 1042 and another organisation’s data comes back.

OWASP places broken object level authorisation first in its API list. It earns that position by being simultaneously the easiest flaw to exploit — no tooling required beyond changing a number — and among the most damaging, because it usually exposes every record of that type rather than one.

Why automated tools do not find it

A scanner recognises patterns it can define. Injection has a signature. A missing header has a signature. An out-of-date dependency has a version number.

Authorisation has no signature, because the correct answer depends on facts the scanner does not hold. It has no way of knowing that record 1042 belongs to a different customer, that this user is a clinician rather than an administrator, or that a departed employee’s token should no longer resolve. Both responses look like a successful request returning JSON.

Most scanners also test as a single session, which forecloses the question entirely. The bug is defined by the relationship between two users, and one session cannot express it.

How is it actually found?

By hand, with at least two accounts and a matrix of role pairs.

The method is unglamorous. Enumerate the roles the system defines: anonymous, standard user, a second standard user in a different tenant, support, administrator, service account, and a former employee whose access should have been revoked. For each pair, take an action that one is entitled to perform and attempt it as the other, changing only the identity or the identifier.

Then repeat for the object types that matter: the records, the documents, the exports, the administrative endpoints, and the operations that appear only in the mobile client or an internal tool.

Test	Question	Found by
Horizontal	Can user A reach user B’s record by changing an identifier?	Manual, two accounts
Vertical	Can a standard role reach an administrative endpoint?	Manual, role matrix
Tenant	Can one customer reach another customer’s data?	Manual, two tenants
Property level	Does the response include fields this role should not see?	Manual, response diffing
Revocation	Does a departed user’s token still work?	Manual, and frequently yes

Why software built quickly is more exposed

Authorisation is the check most easily deferred. The feature works in the demo because everyone testing it owns the records they are looking at. The gap only appears when a second customer exists, and by then the endpoint is in production and the pattern has been copied into six more.

Generated code does not remove the problem and can multiply it, because a plausible endpoint that fetches by identifier is exactly what a model produces when asked for one, and the authorisation check is the part a specification usually leaves implicit.

Why this is where enterprise deals stall

A customer’s security review is often the first time anyone tests the system as two different people. That is an expensive moment to find it: mid-deal, in someone else’s report, with a remediation deadline set by their procurement calendar rather than your release schedule.

In our Enterprise Readiness Assessment the access-control pass is two full days of manual work, and the verification standard now argues our side of the access question for us: meaningful verification requires access to internal artefacts rather than black-box probing.