Scanners miss broken access control because the bug is not in the request. It is in the gap between what the app allows and what it should allow. A request like GET /invoices/1042 is fine when the owner sends it and a breach when another customer sends it. A scanner that does not know who owns invoice 1042, and cannot sign in as a second user to try, has nothing to compare against. It sees a 200 response and moves on.
Updated October 2026
The bug has no signature
Most scanner checks look for a pattern. SQL injection produces database errors or timing changes. Reflected XSS puts a payload back in the page. These are properties of the code and the response, so a tool can test for them the same way on every app.
Access control is different. OWASP lists it as A01 in the Top 10, and the reason is that every app writes its own rules. One app lets a team member read all projects. Another lets them read only their own. The same response can be correct in one and a critical bug in the other. There is no payload that reveals it.
Scanners test as one user
A typical DAST setup gives the scanner one login, or none. With one session, the scanner can only ask "does this request work for me?" It cannot ask "does this request work for someone it should not work for?"
Finding an IDOR (CWE-639) needs at least two accounts: one that owns an object and one that does not. Finding multi-tenant privilege escalation needs accounts in two separate tenants. Finding a role bypass needs an admin and a member. The OWASP testing guide describes this test as a manual one for this reason.
A 200 is not a finding, and a 403 is not safety
Even with two sessions, a scanner has to judge the result. Many apps return 200 with an empty body, a redirect, or a friendly error page when access is denied. Others return 403 for the main route but leak the same data through a GraphQL field, an export endpoint, or a mobile API. A tool that keys on status codes produces both false alarms and misses.
To judge correctly, a tester needs a model of intended access: which roles exist, which objects each role owns or shares, and which actions should be allowed. That model is specific to the app and has to be learned from using it.
SAST sees the code, not the policy
Static analysis can spot a route handler with no authorization middleware. That is useful, and it catches the most obvious cases (CWE-285). But most real access control bugs have a check. It is the wrong check: it confirms the user is logged in but not that they belong to the right organization, or it checks the parent object and not the child. The code looks fine unless you know the intended rule.
What it takes to find these bugs
A tester who finds access control bugs well does four things:
- Signs in as every role and in more than one tenant.
- Maps pages and APIs while noting which objects each user can see.
- Builds a picture of who should reach what.
- Replays each request as users who should be blocked, and checks whether data actually leaked.
Human pentesters do this, but in a fixed window, so coverage depends on time. This is the work an AI pentesting agent can repeat on every release.
A short example
Picture a project tool with two customers, Acme and Globex. An Acme member opens a report and the browser calls GET /api/reports/8812/export. The handler checks that a session exists and that report 8812 exists, then returns the file. It never checks that report 8812 belongs to Acme.
A scanner signed in as the Acme user sees a normal 200 with a CSV. Nothing looks wrong, because for that user nothing is wrong. Only when the same request is sent from a Globex session, and the response still contains Acme's data, does the bug appear. Then a tester has to confirm that the data really belongs to Acme, and that a Globex user who owns a report gets their own file back (the control case). That comparison is the whole test, and it is the part a single-session scanner never makes.
How Wakefield helps
Wakefield agents sign in as every role you give them (admin, member, guest), map pages and APIs, build a model of intended access, and then try to cross user, tenant and role lines. A separate verifier replays each finding with a live exploit and a negative control, and findings it cannot reproduce do not reach you. See the platform and blackbox testing.