broken access control scanner

What is Broken Access Control and Why It Matters

Broken Access Control is the failure of an application to enforce what an authenticated user is allowed to do — so a normal user can read, change, or delete data and reach functions that should be off-limits. Unlike a missing login prompt, the user is often correctly signed in; the flaw is that the server trusts a value it should not (a URL parameter, an object ID, a role field, an HTTP method). That is exactly why it is the hardest class of bug to catch with a generic scanner: the tool has to understand who should own what, not just whether a page loads.

Why it earns its own scanner category:

It sits at the top of the risk list. Broken Access Control was moved to position #1 in the OWASP Top 10 in the year 2021 — the highest rank of any web risk (https://medium.com/meetcyber/broken-access-control-the-1-owasp-risk-explained-in-depth-ee561bde4dd8).
It is nearly universal. Around 94% of tested applications showed some form of access-control weakness in the underlying OWASP dataset (https://medium.com/meetcyber/broken-access-control-the-1-owasp-risk-explained-in-depth-ee561bde4dd8).
It is enforced across trust boundaries, not in the UI: access control depends on prior authentication and session management, and it must live server-side because anything sent from the client can be replayed or edited (https://portswigger.net/web-security/access-control).

The point most scanner reviews miss is why this class defeats naïve tooling — and it changes how you should read scanner output:

There is no "malformed" request to fingerprint. A horizontal-escalation request (GET /orders/1002 while you own 1001) is byte-for-byte valid; the only signal is the response you were not supposed to receive. A signature-based scanner sees HTTP 200 and moves on.
Detection needs at least two identities. You cannot judge whether user A can reach B's data with a single crawl. A scanner that authenticates as only one user is structurally blind to horizontal access control — treat any single-session result as incomplete, not clean.
The oracle is a diff, not a pattern. My working test: capture the same endpoint as an owner and as a stranger, then compare bodies. If the low-privilege response still returns the sensitive object (same record IDs, same field set), it is a confirmed IDOR regardless of status code — a 403 header on a body that still leaks data is a false negative in disguise.

For DevOps this is the practical takeaway: a broken-access-control scanner is only as good as the identities and object references you feed it. Configure it with two real accounts of different privilege and a seed of known-owned object IDs, and grade findings by response-body divergence — not by which status code the server politely returned.

Common Types of Broken Access Control Vulnerabilities

Most write-ups list vulnerability types by name. For a scanner, the more useful axis is where the enforcement check is missing and whether a tool can see it without human context. The categories below are ordered by how reliably an automated broken-access-control scanner can confirm them — which, in practice, decides what you still have to test by hand.

1. Object-level failures a scanner can confirm with two accounts (high detectability) These are identifier-swap bugs: change a numeric id, UUID, or filename in a request issued as user A and receive user B's data. A scanner detects them by replaying the same endpoint under two authenticated sessions and diffing the responses — if low-privilege session A gets a 200 with another tenant's payload, it's a true positive. The hard part is not detection but oracle definition: the tool needs a ground-truth map of which record belongs to which account before it can call a 200 a leak.

2. Function-level / role-boundary failures (medium detectability) Here the endpoint itself should be gated by role, not ownership — creating users, changing prices, exporting logs. A scanner handles these by building a role matrix: crawl the app as an admin, then replay every discovered request as a viewer/anonymous session and flag any that still succeed. This is why broken access control is the hardest class to fully automate — the research on automated authorization testing at https://dl.acm.org/doi/10.1145/3719027.3744825 frames exactly this gap between crawling coverage and verified authorization outcomes.

3. Sequence- and state-dependent failures (low detectability) Multi-step workflows — approve → pay → ship — where step 3 is reachable without steps 1–2, or where a "draft" state is editable after submission. These defeat stateless scanners because a single request looks valid; the flaw only exists across the order of requests. PortSwigger's reference material at https://portswigger.net/web-security/access-control is explicit that this context-dependent class generally needs manual or model-driven testing, not pattern matching.

4. Metadata-trusting failures The server bases its decision on client-supplied trust signals: a role field inside a JWT that isn't re-verified, a hidden form parameter, a cookie like isAdmin, or an X-Original-URL header that bypasses the front-end filter. A scanner probes these by mutating each trust-bearing token/field and watching for privilege change — cheap to attempt, but prone to false positives when the backend silently ignores the injected value.

Why this matters — the baseline numbers Broken Access Control sits at #1 in the OWASP Top 10 (2021), was found in roughly 94% of tested applications, carried an average incidence rate of about 3.81%, produced over 318,000 occurrences across the dataset, and maps to 34 distinct CWEs — figures summarized in the in-depth breakdown at https://medium.com/meetcyber/broken-access-control-the-1-owasp-risk-explained-in-depth-ee561bde4dd8. Read against the four categories above, that 34-CWE spread is the point: no single detection technique covers the class, so a scanner that only does identifier-swapping (category 1) will miss the majority of the 34 patterns by construction.

Practical takeaway for scanner selection When you evaluate a broken-access-control scanner, don't ask "does it find IDOR?" — every tool claims that category 1. Ask for its handling of categories 2–4:

Does it let you feed at least two authenticated sessions with different roles, or only scan anonymously?
Does it persist workflow state between requests, or replay each endpoint in isolation?
Does it re-test after token/field mutation, and how does it suppress the false positives that mutation creates?

A tool that answers "yes" only to category 1 is a parameter fuzzer wearing an access-control label.

How a Broken Access Control Scanner Works

A scanner that finds broken access control does something fundamentally different from one that finds SQL injection or XSS: it cannot judge a single request in isolation. Whether GET /api/orders/1043 is a vulnerability depends entirely on who is asking. So the engine's real job is not pattern-matching payloads — it is proving that a resource reachable by one identity is also reachable by an identity that should be denied. Everything below follows from that constraint.

The core pipeline: crawl → replay → diff

A capable engine runs the target through several distinct identities in parallel and compares them:

Session provisioning. You feed it at least two authenticated contexts (e.g., a high-privilege user and a low-privilege user) plus an anonymous context. Each gets its own cookie jar, tokens, and CSRF handling.
Per-role crawl. It crawls independently as each identity, building a request corpus — URLs, methods, parameters, and body shapes actually seen by that role.
Cross-replay (the actual test). It takes requests discovered by the privileged role and re-issues them under the unprivileged and anonymous sessions, stripping or swapping only the identity material.
Differential oracle. It decides, per replayed request, whether access was wrongly granted.

The whole approach of comparing behaviour across accounts, and of walking predictable identifiers, is described in PortSwigger's access-control material (source: https://portswigger.net/web-security/access-control).

Why the diff step is where scanners live or die

A naive tool checks only the HTTP status. That produces both false negatives (a 200 returning an empty list is not access) and false positives (a soft 200 error page). A serious differential oracle combines signals instead of trusting status codes:

Status code delta between the privileged and unprivileged replay.
Response-body similarity (near-identical bodies for two users often means one user is seeing another's data).
Presence of the owner-specific markers seen in the privileged crawl (account IDs, emails, balances).
Confirmed side effects — a follow-up read that verifies a write (e.g., replay a state-changing PUT, then read the object back as the victim).

This is exactly why generic IDOR-by-fuzzing gives noisy output on real apps; automated broken-access-control checks are still an open, imperfectly solved problem, which is one reason the category dominates real-world findings (source: https://outpost24.com/blog/broken-access-control-and-scanners/).

Object-level vs. function-level probing

The engine has to attack two different failure modes with different tactics:

Object-level (IDOR): mutate identifiers in the authorized user's own traffic — increment/decrement numeric IDs, swap UUIDs harvested from the other session, tamper with references in JSON bodies and JWT claims — then check whether foreign objects come back.
Function-level: replay privileged actions (admin endpoints, hidden methods, DELETE/PATCH on read-only UIs) under a low role, including method-override and forced-browsing variants.

Scope and why coverage matters more than payloads

Because the risk is context-dependent, the value of the scanner is proportional to how much of the app it can authenticate into and how many role pairs it can diff — not how many payloads it fires. That coverage problem is why this class stays the top web risk: it was found in 94% of tested applications with an average incidence rate of 3.81%, and it aggregates 34 distinct CWEs, meaning a scanner must model many concrete weakness patterns under one umbrella (source: https://medium.com/meetcyber/broken-access-control-the-1-owasp-risk-explained-in-depth-ee561bde4dd8).

The practical takeaway for configuring such a tool: give it more identities and richer authenticated crawl seeds, not more attack strings. Two well-provisioned sessions with clean logout/token handling will surface more real broken-access-control bugs than a thousand blind payloads against a single login.

Key Features to Look for in a Broken Access Control Scanner

Most tools that advertise "broken access control detection" are really generic crawlers with a rules pack bolted on. The category resists automation for one structural reason: a request that is perfectly legal for one identity is a breach for another, and a scanner sees only HTTP — not who should be allowed. So instead of ranking features by popularity, evaluate a scanner by a single decisive test and then by what supports that test.

The decisive test: does it run the same request under two identities and compare the answers? Ask the vendor to prove the tool can take a captured action by User A and replay it as User B (or as no user at all) and flag the cases where the response is identical. If it can't do identity-swapped differential replay, it cannot find IDOR or horizontal escalation no matter how many signatures it ships — it can only find the leftovers that PortSwigger groups under unprotected functionality and parameter-based access, not the context- and identity-dependent flaws it explicitly calls the hardest to detect (https://portswigger.net/web-security/access-control). Everything below is only useful in service of this test.

Supporting capabilities that make the test possible:

Multi-session authentication that actually holds. The scanner must keep several authenticated sessions alive in parallel (admin, standard user, unauthenticated) and re-login automatically when a token expires mid-scan — otherwise the "swap" silently degrades into comparing two logged-out responses.
Stateful recording, not stateless crawling. It should learn object identifiers and sequences from User A's traffic, then reuse them as User B. Outpost24 makes the same point from the defender's side: generic DAST rarely understands application state well enough to catch these issues and usually needs authenticated, context-aware testing to reach them at all (https://outpost24.com/blog/broken-access-control-and-scanners/).
Response-diff logic beyond status codes. A 200 that returns another user's record is the bug; a tool that trusts 403/200 alone will miss it. Look for content-similarity comparison with a tunable threshold and for catching force-browsing that skips the UI entirely.

Why this matters more than check count. Broken access control sits at #1 on the OWASP Top 10, and the 2021 data behind that rank — 94% of tested applications contained some form of it, with a 3.81% average incidence rate, the most of any category — is driven almost entirely by the identity-dependent cases single-pass scanners ignore (https://medium.com/meetcyber/broken-access-control-the-1-owasp-risk-explained-in-depth-ee561bde4dd8). A scanner with hundreds of checks but no identity-swap engine will inflate its detection-rate marketing while leaving the bulk of real exposure untouched.

Operational features worth confirming (in priority order):

Role/identity matrix you can define per endpoint, so the tool knows the expected permission and can call a silent success a finding.
CI/CD-friendly execution with authenticated scans triggered per build — because access rules break on every refactor, not once a quarter.
Low false-positive posture on diffs (evidence pairs shown side by side) so developers trust the results instead of muting them.
API-native testing that parses OpenAPI/GraphQL schemas, since most modern IDOR lives in object-level API endpoints rather than HTML forms (https://pentest-tools.com/website-vulnerability-scanning/website-scanner).

If a product can't demonstrate identity-swapped replay on your own staging app in a short trial, treat its "broken access control" label as marketing, not capability.

Manual Testing vs Automated Scanning for Access Control Flaws

Access-control testing is one of the few security domains where the tool cannot know the intent behind a request. A scanner sees an HTTP 200; only a human knows that user B was never supposed to read invoice #4471. That gap defines the whole manual-vs-automated split, and it is why treating a "broken access control scanner" as a complete solution is a mistake even though this category tops the risk charts — OWASP's 2021 data, summarized in this write-up, found broken access control in 94% of tested applications (https://medium.com/meetcyber/broken-access-control-the-1-owasp-risk-explained-in-depth-ee561bde4dd8). A 94% prevalence rate means the flaw is essentially the default state, not the exception, so your process has to assume it is present rather than wait for a tool to prove it.

What to hand to the scanner Automation is efficient exactly when the "correct" answer is context-free and repeatable across every account:

Missing authentication on endpoints (a 200 with no session at all).
Predictable object references you can enumerate — sequential IDs, base64-wrapped integers, UUIDs leaked in earlier responses.
Method-based bypasses (GET blocked, but PUT/DELETE allowed).
Forced-browsing to routes not linked in the UI.

The non-negotiable prerequisite: give the scanner at least 2 authenticated sessions — a low-privilege and a high-privilege token — so it can diff responses. A single-session crawl cannot detect horizontal escalation at all; it has nothing to compare against. That same year the category was promoted to the number-1 position in the OWASP Top 10, replacing injection (https://medium.com/meetcyber/broken-access-control-the-1-owasp-risk-explained-in-depth-ee561bde4dd8), which tells you where to spend your two-account setup effort first.

What only a human can decide Manual testing owns every case where authorization depends on data the scanner cannot interpret:

Multi-step workflow state (can you POST step 5 before completing step 3?).
Ownership tied to business rules ("a manager sees their team's records, not all records").
Approval and self-approval abuse (submitter approving their own request).
Parameter tampering where the value changes meaning — role=user vs role=admin in a JWT the scanner treats as opaque.

My working split: let automation handle enumeration and coverage across the full route map, then reserve manual time for the 5–10 highest-value objects (payments, PII exports, admin toggles) where a false 200 is a breach, not a finding. Confirm every automated hit by hand — scanners flag the anomaly, but a human confirms the authorization intent was actually violated.

Best Practices for Preventing Broken Access Control

Access control breaks in ways that unit tests rarely catch, so the goal of prevention is not "add checks" — it is to make authorization externally verifiable, so a scanner (and a reviewer) can prove each rule holds. Build the system so that every allow/deny decision is observable, replayable, and centralized. The practices below are ordered to maximize that verifiability.

1. Collapse authorization into one enforcement layer. Scatter your checks across controllers and no tool can reason about them; route every decision through a single policy component. This matters because broken access control has held the #1 rank in the OWASP Top 10 since 2021 precisely because it is a distributed design flaw, not one missing if statement (source: https://medium.com/meetcyber/broken-access-control-the-1-owasp-risk-explained-in-depth-ee561bde4dd8). A single choke point gives your scanner one contract to hammer instead of hundreds.

2. Ship an authorization matrix as code. Maintain a machine-readable table of (role × endpoint × object-ownership) → expected status. This artifact does double duty:

It is the spec developers implement against.
It is the exact input a scanner replays to detect drift.

3. Test with two identities, differentially, in CI. The cheapest reliable detector for IDOR and privilege escalation is a replay harness: capture a legitimate request from a high-privilege session, resend it with a low-privilege token, and fail the build on any response that should be 403 but returns 200. Cover all three families PortSwigger separates — vertical, horizontal, and context-dependent — because a scanner that only tests one of these 3 categories will pass code that is still exploitable (source: https://portswigger.net/web-security/access-control).

4. Never let the client's identifier be authoritative. Accept the object ID from the request, but re-derive ownership server-side from the session subject on every call. Unguessable IDs (UUIDs) are hardening, not a control — treat them as defense-in-depth only.

5. Deny by default at the router. Any endpoint without an explicit policy entry should be unreachable, so new routes fail closed. This turns "forgot to add a check" from a silent vulnerability into a 403 you notice immediately.

6. Instrument denials as a signal, not just an error. Log every authorization rejection with subject, object, and rule ID. A spike in denials from one account is often reconnaissance in progress, and it feeds your scanner's coverage report: endpoints that never emit a deny event are endpoints no test ever exercised negatively.

The through-line: don't prevent broken access control by writing more checks — prevent it by making your checks something a machine can enumerate, replay, and disprove.