How to Test Broken Access Control (OWASP A01) 2026

Testing OWASP A01:2025 Broken Access Control means manually verifying that every server-side request enforces the correct authorization check for the requesting user's role, tenant, and record ownership — not just confirming a login screen exists. The direct path runs through vertical privilege-escalation testing, horizontal insecure direct object reference (IDOR) checks, forced browsing against unlinked endpoints, and JWT or session tampering, all validated with authenticated low-privilege accounts against every state-changing and data-returning endpoint. Automated scanners flag missing headers and outdated libraries; they cannot determine whether a mid-tier account can read another tenant's invoice, which is why access control failures require a manual, hacker-led verification pass before a system reaches production or a compliance audit in 2026.

TL;DR

• Testing broken access control (OWASP A01) requires manual verification of authorization on every endpoint — scanners cannot validate business logic.
• Three failure classes matter most: vertical privilege escalation, horizontal IDOR, and missing function-level access control.
• OWASP's Top 10 analysis found broken access control present in 94% of applications tested, the highest occurrence of any category.
• PortSwigger Web Security Academy's access control and IDOR labs provide safe, authorized environments to practice exploitation technique.
• AppSecure's hacker-led penetration testing validates exploitability and business impact, not just theoretical misconfiguration.

Why This Matters

Broken Access Control topped the OWASP Top 10 in 2021 and remains the most exploited category heading into 2026 because it fails silently. The request succeeds, the response looks correct, and nothing in a WAF log flags it as malicious. A tenant reading another tenant's records, a support agent escalating to admin, or an unauthenticated call reaching an internal API endpoint all return HTTP 200. That single characteristic — a valid-looking response hiding an authorization failure — is why access control defects survive code review, unit tests, and automated DAST scans that only check for the presence of a control, not whether it's enforced correctly for every role and object.

For regulated software vendors, an access control failure is also a compliance failure. PCI DSS Requirement 7 and 8, SOC 2 CC6.1, and ISO 27001 Annex A.8.3 all require documented, tested access restrictions, and a single IDOR in a payment flow can void an audit finding regardless of how hardened the rest of the stack is. Most exploitable access control bugs live in API responses rather than the UI, which is why how to conduct an API penetration test should run alongside any A01 assessment rather than as a separate engagement.

How to Test OWASP A01:2025 Broken Access Control

Start by mapping every role, tenant tier, and object type the application exposes, then test each request against a role that should not have access to it. The table below summarizes the failure classes a tester validates during an A01 assessment.

Vertical privilege escalation

• Description: Low-privilege user reaches an admin-only function
• Example: Support agent's session calls /admin/users directly

Horizontal privilege escalation (IDOR)

• Description: User accesses another user's record by changing an identifier
• Example: Changing invoice_id=1042 to 1043 returns another customer's invoice

Missing function-level access control

• Description: Endpoint has no server-side role check
• Example: API accepts DELETE /projects/{id} from any authenticated session

CORS misconfiguration

• Description: Origin reflection with credentials lets any domain read authenticated responses
• Example: Access-Control-Allow-Origin reflects the request origin with credentials: true

BOLA in APIs and GraphQL

• Description: Object-level authorization missing from the response layer
• Example: GraphQL query returns fields for objects the caller doesn't own

Horizontal Privilege Escalation and IDOR

Create two low-privilege test accounts on separate tenants or user records, capture every object identifier they generate, then swap identifiers across sessions using an intercepting proxy. Test sequential integers, UUIDs, and encoded or hashed identifiers separately — a UUID slows down guessing but does not fix the missing authorization check if the value is still accepted cross-account. Run the same swap on read, write, and delete operations, since teams frequently protect the GET endpoint but forget the PATCH or DELETE route for the same object. Multi-tenant products carry the highest exposure here, because a single missing tenant_id filter in one query can expose every customer's data; see penetration testing for multi-tenant SaaS architectures for tenant-isolation test cases specific to shared-database designs.

Vertical Privilege Escalation

Build a role matrix — at minimum an unauthenticated, standard-user, and admin account — and replay every admin API call recorded during a legitimate admin session using the standard-user's session token. Check whether the role is enforced server-side or only hidden in the UI, and inspect JWTs for a role or permissions claim a client could tamper with before the token is verified. A privilege check performed only in the front-end code is not a privilege check — the server must reject the request independent of what the UI renders.

Missing Function-Level Access Control and Forced Browsing

Enumerate the full endpoint surface using the OpenAPI/Swagger spec, GraphQL introspection, and JavaScript bundle analysis to recover routes never linked from the visible UI. Call each discovered endpoint with a lower-privilege token and with no token at all, and flag any response that returns data or performs an action instead of a 401 or 403. Administrative and internal tooling routes — reporting dashboards, debug endpoints, feature-flag toggles — are the most common source of missing function-level checks because they were never expected to be reached directly.

CORS Misconfiguration and JWT or Token Tampering

Send requests with an arbitrary Origin header and check whether the server reflects it in Access-Control-Allow-Origin while also setting Access-Control-Allow-Credentials: true — that combination lets a malicious page read authenticated responses on behalf of a logged-in victim. On the token side, test whether the API accepts alg: none, a weak or guessable signing secret, an expired token, or a token replayed after logout; also confirm aud and iss claims are validated so a token issued for one service cannot be reused against another.

Manual Testing Workflow

1. Scope and prerequisites — confirm role definitions, tenant boundaries, and which environments are in scope before any request is sent.
2. Build a role matrix — provision test accounts across every privilege tier, including any support, billing, or read-only roles.
3. Enumerate the attack surface — pull endpoints from API specs, mobile app decompilation, GraphQL introspection, and JS source maps.
4. Test authorization at every layer — repeat each test case at the UI, API, and data layer, since a fix at one layer often leaves the others exposed.
5. Chain findings — combine an IDOR with a mass-assignment bug or an exposed internal ID to measure real business impact, not just theoretical exposure.
6. Capture evidence — save request and response pairs, timestamps, and account context for every confirmed finding.
7. Validate and retest — confirm findings are reproducible from a second session, then retest after remediation to close the loop.

Why Manual Testing Finds What Scanners Miss

DAST and SAST tools check for the presence of security headers, known vulnerable libraries, and pattern-matched injection points — they have no concept of whether user 4021 should be permitted to see order 8834. That judgment requires a human to build a role matrix, understand the application's data model, and try the request from the wrong account. PortSwigger's Web Security Academy documents this gap directly through its Access Control Vulnerabilities and Insecure Direct Object References labs, which are built specifically because scanners consistently pass applications that contain exploitable authorization flaws. AppSecure's hacker-led penetration testing methodology mirrors that lab-based approach in live engagements: testers build the role matrix, manually chain access control gaps with business-logic flaws, and validate exploitability before a finding is reported — not a scanner-generated list of theoretical misconfigurations.

Common Access Control Findings and Business Impact

IDOR on invoice or billing endpoint

• Business Impact: Cross-customer financial data exposure; PCI DSS and GDPR breach notification risk

Missing function-level check on admin API

• Business Impact: Full account takeover and audit finding

JWT alg: none accepted

• Business Impact: Complete authentication bypass

Excessive CORS trust with credentials

• Business Impact: Session token theft via cross-origin script

Client-supplied tenant ID trusted

• Business Impact: Cross-tenant data leakage across a shared multi-tenant database

Compliance Mapping for Access Control Testing

PCI DSS

• Requirement: Req. 7 & 8 — restrict access by business need-to-know
• What Assessors Check: Server-side role enforcement with pentest evidence of testing

SOC 2

• Requirement: CC6.1, CC6.3
• What Assessors Check: Logical access controls and periodic penetration test results

ISO 27001

• Requirement: Annex A.8.2 / A.8.3
• What Assessors Check: Access restriction controls validated through testing evidence

HIPAA

• Requirement: 45 CFR 164.312(a)
• What Assessors Check: Access control mechanisms tested for systems holding ePHI

Assessors under any of these frameworks expect a report that names the specific endpoints tested, the roles used, and the remediation status — not a generic statement that "access controls were reviewed."

How to Choose a Provider for Access Control Testing

Access control findings only matter if they're validated for exploitability and mapped to business impact, so the evaluation criteria differ from a generic vulnerability scan vendor. Look for a provider that builds a full role matrix before testing begins, tests authentication and session handling alongside authorization — see how to penetration test a single sign-on system for how SSO and identity layers interact with access control — and retests after remediation rather than closing the engagement at the initial report. AppSecure runs these engagements with a hacker-led methodology built around manual attack-path discovery and privilege-boundary analysis, which is the same standard SaaS, fintech, and healthcare teams need heading into a SOC 2 or PCI DSS cycle in 2026.

Get an access control assessment

Validate authorization gaps before an auditor or attacker finds them.

Talk to AppSecure

Broken Access Control Testing Checklist

• Role matrix built for every privilege tier, including support and read-only roles
• IDOR tested on sequential, UUID, and encoded identifiers across read/write/delete operations
• Function-level checks verified server-side, not inferred from UI behavior
• CORS policy tested with credentialed cross-origin requests
• JWT signature, algorithm, and audience/issuer claims validated
• Mobile and API clients tested independently of the web UI
• Tenant isolation confirmed at the database query level, not just the API layer
• Retest performed after remediation, from a fresh authenticated session

Is Broken Access Control the Same as IDOR?

IDOR is a subtype of broken access control, not a synonym for it. Broken access control (OWASP A01) covers every failure to enforce authorization correctly, including vertical privilege escalation, missing function-level checks, and CORS misconfiguration, while IDOR specifically describes horizontal access failures where changing an object identifier exposes another user's data.

How Often Should Access Control Be Retested?

Access control should be retested after every major feature release, before any compliance audit cycle, and at minimum once a year for applications handling regulated data. New endpoints, new roles, and new tenant structures each introduce fresh authorization logic that hasn't been validated against the existing role matrix.

Can Automated Scanners Detect Broken Access Control?

Automated scanners cannot reliably detect broken access control because the vulnerability lives in business logic, not in a signature or pattern. A scanner can confirm a login page exists and that TLS is configured correctly, but it has no way to know that account 4021 should never be permitted to read order 8834 — that judgment requires a manually built role matrix and a tester attempting the request from the wrong account.

FAQ

What is OWASP A01 Broken Access Control?

OWASP A01 Broken Access Control is the top category in the OWASP Top 10, covering failures where an application does not correctly enforce what an authenticated user is permitted to see or do. It includes privilege escalation, IDOR, missing function-level checks, and CORS misconfiguration.

How do you test for IDOR vulnerabilities?

Test for IDOR by creating two low-privilege accounts, capturing the object identifiers each generates, and swapping them across sessions using an intercepting proxy on read, write, and delete requests. Test sequential integers, UUIDs, and encoded identifiers separately, since obfuscation alone does not fix a missing authorization check.

What tools are used to test broken access control?

An intercepting proxy such as Burp Suite is the core tool, paired with authenticated test accounts across every role tier and an API specification for endpoint enumeration. PortSwigger's Web Security Academy access control and IDOR labs provide a safe environment to practice the underlying technique before testing production systems.

Is broken access control testing part of API penetration testing?

Yes, broken access control testing is a core component of API penetration testing since most exploitable authorization failures surface in API responses rather than the rendered UI. Object-level and function-level authorization checks should be validated on every API endpoint independent of the web client.

Why do access control vulnerabilities pass code review?

Access control vulnerabilities pass code review because the missing check is an absence, not a visible flaw, and reviewers often assume authorization is handled by a shared middleware layer that doesn't actually cover every route. Manual penetration testing catches these gaps by attempting the request from an unauthorized account rather than reading the code in isolation.

Does PCI DSS require access control testing?

PCI DSS Requirements 7 and 8 require access to cardholder data be restricted by business need-to-know, and penetration testing evidence is expected to demonstrate that restriction is enforced server-side. A single IDOR exposing another cardholder's data in scope can result in a failed assessment.

What is the difference between vertical and horizontal privilege escalation?

Vertical privilege escalation occurs when a lower-privilege user reaches functionality reserved for a higher role, such as a standard user calling an admin endpoint. Horizontal privilege escalation occurs when a user at the same privilege level accesses another user's data by manipulating an object identifier.

How long does a broken access control assessment take?

The duration depends on the number of roles, tenants, and API endpoints in scope, since the tester must build a full role matrix and test each endpoint from multiple privilege levels. Applications with complex multi-tenant or multi-role structures require more testing time than a single-role application with a small API surface.

One Last Thing

Most IDOR fixes fail the first retest because engineering teams patch the exact endpoint the tester found and leave the other endpoints exposing the same object type untouched. If a GET /invoices/{id} route was vulnerable, check the PATCH, DELETE, and any bulk-export route for the same object before calling the fix complete — access control gaps rarely exist in isolation, and a retest that only re-checks the original request will miss the sibling endpoint an attacker finds next.

Related Guides

• Kubernetes penetration testing for SaaS platforms
• Best penetration testing services for SaaS companies