Broken access control has held the top position in the OWASP Top 10 since 2021, and OWASP confirmed it again in the 2025 update. Before 2021 it ranked fifth. The jump to first reflects a measurement change that tells a specific story: when testing methodology improved to actually look for authorization flaws, they turned up more consistently than any other vulnerability class.
The reason it tops the list is not that authorization logic is newly broken. It is that authorization flaws are structurally invisible to the scanning tools that most organisations rely on for security coverage. A scanner can find that your login endpoint does not enforce rate limiting. It cannot find that your invoices API returns any customer's invoice when the invoice ID is incremented by one. Finding that requires a different kind of test entirely.
This post covers what broken access control actually encompasses, why it has been consistently undercounted in application security programmes, and what testing methodology actually surfaces it.
Broken access control is not a single vulnerability: it is a category covering every failure mode where an application allows users to act outside their intended permissions. OWASP A01 groups several distinct attack sub-classes under this label, each with different technical mechanics.
IDOR is the most common and most recognisable BAC sub-class. The application references internal data objects directly through user-controlled identifiers (document IDs, user IDs, order numbers, account references) without verifying that the requesting user is authorised to access the referenced object.
How it works: A user requests their own invoice at /api/invoices/10482. The application returns it. The user changes the ID to /api/invoices/10483. The application returns that invoice too, belonging to a different customer. The application checked that the user was authenticated. It did not check that invoice 10483 belongs to this user.
Why it is so common: Developers build object retrieval logic at the data access layer and apply authentication checks at the endpoint layer. The two layers do not always communicate. The authentication check confirms the user is logged in; nobody added an ownership check to confirm the retrieved object belongs to this user.
The scale of the problem: In a multi-tenant application with thousands of customers, every object reference is a potential IDOR. An attacker who discovers the pattern can enumerate object IDs systematically.
Vertical escalation occurs when a user with lower privileges accesses functionality or data reserved for higher-privilege roles. A standard user accessing administrator functions. A read-only user triggering write operations. A customer accessing employee-only data.
How it works: An application exposes admin functionality at /admin/users/export. The endpoint checks whether the request includes a valid session token but does not verify that the session belongs to an administrator account. Any authenticated user who discovers the endpoint can trigger the export.
The route discovery problem: Attackers do not need the URL to be advertised. Endpoint URLs can be discovered through JavaScript bundle analysis, network traffic observation, API documentation, error messages, or simple prediction from the existing URL structure. Security through obscurity is not access control.
BFLA is vertical escalation at the API function level. The application exposes API endpoints that perform privileged operations (user deletion, account configuration, data export) without enforcing that the caller holds the role required for those operations.
How it works: A SaaS platform exposes DELETE /api/users/{id} for administrator use. The endpoint validates the session token but does not check whether the token belongs to an administrator session. A standard user with a valid session token can delete any user account.
Why BFLA is particularly dangerous in REST and GraphQL APIs: REST APIs often expose CRUD operations at predictable endpoints. GraphQL exposes an introspection endpoint that can reveal available operations including those intended for privileged users only. API vulnerabilities standard penetration tests miss covers BFLA as one of the most consistently missed API vulnerability classes.
JSON Web Tokens carry user identity and role claims that the application trusts to make access decisions. If the JWT implementation does not validate signature integrity correctly, or if algorithm confusion attacks are possible, an attacker can modify their own JWT to claim a higher role.
How it works: A user's JWT contains {"role": "user"}. The application makes access decisions based on this claim. If the application accepts unsigned tokens, accepts the none algorithm, or uses a weak secret, the attacker can modify the claim to {"role": "admin"} and forge a valid signature. The access control layer reads the role from the token without independent verification.
Why this matters for access control testing: JWT vulnerabilities are an access control failure, not just a cryptographic one. The impact of a JWT attack is not cryptographic compromise: it is that the attacker can claim any identity or role the application trusts.
Path traversal vulnerabilities allow attackers to access files and directories outside the intended access scope by manipulating file path references. This is broken access control at the file system layer.
How it works: An application serves files at /documents/{filename}. The intended files are in /var/app/documents/. An attacker requests /documents/../../../../etc/passwd. The application constructs the path without validation and reads the system password file.
Why this persists: Path traversal is well-known and straightforward to prevent, yet it appears consistently in penetration test findings. The gap is typically in file-handling code that was written without security review, in third-party libraries that handle file access, or in edge cases like filename encoding variants that bypass incomplete sanitisation.
This is the core question the brief raises, and it deserves a precise answer rather than a general claim.
A vulnerability scanner operates on a simple model: send a payload to an input, observe the response, match the response against known vulnerability signatures. SQL injection scanners send SQL payloads and check for database error patterns. XSS scanners inject script tags and check whether they appear in the response. The scanner does not need to understand what the application is supposed to do: it just needs to recognise the signature of what went wrong.
Authorization flaws do not have signatures. They are contextual failures.
The single-session problem: A scanner operates as one user in one session. To find that user A can access user B's data, a test must be conducted by a user who is user A, requesting data that belongs to user B, and verifying that the application returns it when it should not. This requires two simultaneous identities. A scanner operating as a single authenticated session cannot establish that the data it receives belongs to a different user: it receives data
The knowledge-of-intent problem: Scanners match signatures against known bad patterns. An IDOR vulnerability does not have a "bad pattern" signature: the response looks like a successful data retrieval, which is also what a legitimate response looks like. Distinguishing the two requires knowing what data each user is supposed to have access to. The scanner does not have that knowledge. The application's authorization logic is the only place where that check can occur, and if that logic is wrong, the scanner sees nothing wrong.
The business logic dependency: Access control rules are application-specific. "User A can read documents they own, but not documents owned by user B, unless user B has explicitly shared them" is a business rule that cannot be expressed as a vulnerability signature. Every application has different rules. A scanner that does not know the rules cannot test whether they are enforced.
The scale of the coverage gap: In a DAST scan of a web application, DAST fires payloads at accessible inputs and checks responses for known vulnerability patterns. Authorization gaps produce responses that look exactly like legitimate responses. How DAST compares to agentic AI pentesting on real-world coverage maps this gap in full. The security gaps DAST and standard testing misses covers the broader class of vulnerabilities that signature-based testing structurally cannot find.
Finding authorization flaws requires testing from multiple simultaneous authenticated positions and reasoning about whether the application's responses match what the access rules should permit.
Multi-role session architecture: An agentic penetration testing system creates and maintains concurrent sessions for each user role defined in the scope (standard user, team administrator, billing administrator, organisation owner, read-only user, and any other roles the application supports). Each session is a distinct authenticated identity with its own credentials, session tokens, and access entitlements.
Cross-role object access testing: With sessions for user A and user B established simultaneously, the agent can request objects belonging to user A using user B's session, and verify whether the application returns them. This is the test that directly confirms an IDOR vulnerability. The agent knows what user A's objects are because it accessed them using user A's session. It can then test whether those same objects are accessible using user B's session. The scanner cannot do this because it has only one session.
Vertical escalation mapping: The agent enumerates accessible endpoints and functions for each role, then tests whether lower-privilege sessions can access the functions that only higher-privilege sessions should reach. For each function accessible by an administrator session, the agent tests whether a standard user session can also invoke it. This is BFLA testing at systematic scale.
Reasoning about authorization patterns: Agentic systems observe patterns in how the application constructs resource identifiers. Sequential numeric IDs suggest IDOR testing across ranges. UUIDs suggest testing whether predictability or enumeration is possible through other means. The agent reasons about the identifier scheme and designs its testing accordingly: not from a signature library but from observation of the application's own structure.
JWT and token manipulation testing: The agent examines the tokens issued during authentication, identifies the claim structure, and tests whether modifications to role or identity claims are accepted. This includes algorithm confusion testing, unsigned token acceptance, and claim injection.
Agentic pentesting and continuous security validation covers the architecture. Penetration testing automation: beyond scripted scans covers why the automation level matters for finding this class of vulnerability. IAST tools can observe authorization decisions at the code level during test execution. IAST security testing explained: where it sits between DAST and SAST covers where IAST fits relative to the testing approaches above.
When commissioning penetration testing, the scope and methodology specification directly determines whether BAC will be found. Penetration testing scope: how to define it before you start covers scope definition generally. For BAC specifically:
Ask whether the engagement provides multiple authenticated sessions. If the vendor tests your application as a single authenticated user, they cannot find IDOR or BFLA. The engagement must include credentials for every user role in the application. Confirm this in the pre-engagement requirements.
Ask what the vendor's specific IDOR testing methodology is. A vendor who describes their IDOR testing as "we look for sequential IDs in URL parameters" is describing a narrow slice of IDOR coverage. A vendor who describes systematic cross-role object access testing across all resource types is describing comprehensive coverage.
Ask about API authorization testing specifically. REST and GraphQL APIs have distinct authorization attack surfaces from web application UIs. BFLA testing requires specifically testing API endpoints that perform privileged operations with lower-privilege sessions. Confirm the engagement includes this.
Ask what methodology is used for privilege escalation testing. Comprehensive vertical escalation testing requires a complete map of role-specific functionality and systematic testing of each function from each lower-privilege session.
Confirm that the engagement produces confirmed exploitable findings, not scanner output. A scanner output that lists "potential access control issues" identified through signature matching is not a BAC assessment. Confirmed findings with proof-of-exploitation evidence (the specific request that accessed another user's data, the response that demonstrated success: this is the evidence standard for BAC findings.
What a real web application penetration test should cover maps the full coverage dimensions that a web application test should address. Continuous penetration testing and how it differs from annual pentests covers why BAC testing needs to run at deployment cadence: new features routinely introduce new access control patterns that were not present in the last annual assessment.
When BAC findings are confirmed through testing, remediation requires addressing both the specific finding and the pattern that produced it. The security gaps DAST and standard testing misses covers how testing methodology determines what remediations are prioritised.
For IDOR: Implement ownership verification at the data access layer, not only at the endpoint layer. Every query that retrieves an object by ID should include a constraint that filters for objects owned by the authenticated user, not as a post-retrieval check, but as part of the query itself. A query that returns any invoice by ID and then checks ownership after retrieval has a race condition and a logging gap that ownership-filtered queries avoid.
For vertical escalation and BFLA: Enforce role checks as middleware or as a decorator pattern applied to every endpoint, rather than as ad hoc checks within individual endpoint handlers. Ad hoc role checks are missed as endpoints are added. Centralised middleware applies consistently. Verify the role check operates on the server-side session, not on a client-controlled parameter.
For JWT attacks: Validate the algorithm header against an explicit allow-list of accepted algorithms. Never accept none. Use asymmetric keys for tokens that carry privilege claims. Rotate secrets regularly.
For path traversal: Canonicalise file paths before validation. Validate against an allow-list of permitted directories after canonicalisation. Never construct file paths by concatenating user-supplied input.
For penetration testing services in the US that include multi-role broken access control testing as standard coverage, agentic penetration testing for continuous multi-role authorization testing at deployment cadence, and PTaaS for the ongoing model, the 10x Pentest platform covers application and API security testing including the BAC coverage that scanners cannot provide. See pricing or get in touch to discuss whether your current testing programme is actually testing authorization controls.
Q1. What is broken access control?
Broken access control is the OWASP A01 category covering every failure mode where an application allows users to act outside their intended permissions. It encompasses several distinct attack sub-classes: IDOR (Insecure Direct Object References), where users access objects belonging to other users by manipulating resource identifiers; vertical privilege escalation, where lower-privilege users access functionality reserved for higher-privilege roles; BFLA (Broken Function-Level Authorization), where API endpoints performing privileged operations do not enforce role requirements; JWT claim manipulation, where weaknesses in token validation allow attackers to forge elevated privilege claims; and path traversal, where file access controls are bypassed through path manipulation. It has topped the OWASP Top 10 since 2021 and was confirmed at the top position in the 2025 update.
Q2. Why do vulnerability scanners miss broken access control?
Scanners cannot find authorization flaws because authorization failures do not produce vulnerability signatures. A scanner operates as a single authenticated session and matches application responses against known bad patterns. An IDOR vulnerability produces a response that looks exactly like a legitimate successful data retrieval: the scanner has no way to distinguish between "the application correctly returned this user's data" and "the application incorrectly returned another user's data." Detecting the second requires knowing what data each user is authorised to access, which requires operating as multiple users simultaneously and comparing what each receives. Scanners are single-session tools built on signature matching; authorization testing requires multi-session reasoning.
Q3. How does agentic penetration testing find broken access control?
Agentic penetration testing maintains concurrent authenticated sessions for every user role defined in scope (standard user, administrator, read-only user, and any other roles the application supports). With multiple live sessions, the agent can request objects belonging to one user's session using another user's session and verify whether the application returns them: this is the direct test for IDOR. It maps all functions accessible by administrator sessions and tests whether lower-privilege sessions can invoke them: BFLA testing at systematic scale. It reasons about resource identifier patterns to design targeted cross-role access tests. This multi-role, reasoning-based approach is what the scanner's single-session, signature-matching architecture cannot replicate.
Q4. What is IDOR and why is it so common?
IDOR (Insecure Direct Object Reference) is the broken access control sub-class where an application uses user-controlled identifiers to reference internal data objects (invoice IDs, user IDs, document numbers, order references) without verifying that the requesting user is authorised to access the referenced object. It is common because developers frequently implement authentication checks and ownership checks as separate concerns. The authentication layer verifies the user is logged in. The data retrieval layer returns the requested object by ID. When the ownership check is omitted from the data retrieval layer, any authenticated user can access any object by changing its identifier. In multi-tenant applications, every object reference is a potential IDOR finding.
Q5. How do you prevent broken access control?
Prevention requires enforcing access control at every layer of the application. For object-level access (IDOR): implement ownership checks as part of the database query, not as a post-retrieval filter: a query that filters by both object ID and authenticated user ID cannot return another user's data regardless of what ID is requested. For function-level access (BFLA and vertical escalation): apply role checks as centralised middleware applied uniformly to all endpoints, not as ad hoc checks within individual handlers: ad hoc checks are missed as the application grows. For JWT tokens: validate the algorithm against an explicit allow-list, use asymmetric keys for privilege-bearing tokens, and never accept unsigned tokens. For file access: canonicalise paths before validation and validate against an allow-list of permitted directories. After remediation, commission a retest that specifically covers multi-role authorization testing to confirm the fixes hold under adversarial conditions.
A medium IDOR plus a low session token issue plus an informational error disclosure is not three low-risk findings. It can be a full account takeover. Attack path analysis reveals which chains lead to real breach routes.
Tejas Dhokane Oct 5, 2026 
OWASP promoted software supply chain to A03 in 2025. Every result explains what supply chain attacks are. This post covers what supply chain security testing actually involves and what it finds.
Tejas Dhokane Sep 30, 2026 
The pentest report is the beginning of the security work, not the end. This guide maps the full remediation lifecycle — triage, routing, developer handoff, SLAs, retest, and compliance evidence.
Tejas Dhokane Sep 18, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
