API1:2023 Broken Object Level Authorization (BOLA) is tested by mapping every endpoint that accepts an object identifier, then attempting to access, modify, or delete objects that belong to a different user or tenant using an authenticated low-privilege session. The vulnerability exists when the API checks that a request is authenticated but never verifies that the requester actually owns the object referenced in the URL, path parameter, or request body.
TL;DR
- BOLA testing means swapping object IDs across user contexts to confirm the API enforces ownership, not just authentication.
- API1:2023 is ranked #1 in the OWASP API Security Top 10 and maps to CWE-639, Authorization Bypass Through User-Controlled Key.
- Manual testing catches BOLA far more reliably than automated scanners because the flaw is a logic gap, not a signature.
- Every object-returning endpoint needs an authorization matrix: role, tenant, and object owner tested against every other identity.
- PCI DSS, SOC 2, and ISO 27001 assessors all expect object-level authorization testing as part of API penetration testing evidence.
Why This Matters
BOLA is not a new bug class. It has topped the OWASP API Security Top 10 since the list existed, and it remains the single most exploited API flaw reported in 2026 incident write-ups because it requires no exploit code, just a changed ID in a request. A single unauthorized object access on a fintech or healthcare API can expose account balances, medical records, or PII belonging to every customer in the system, not just the tester's own account.
Regulators treat BOLA as an access control failure, not a minor bug. PCI DSS 4.0, SOC 2 Type II, HIPAA, and ISO 27001 assessors all expect evidence that object-level authorization was tested against every role and tenant combination, not just validated once during design. AppSecure's penetration testing services build BOLA test cases into every API engagement because scanners consistently miss this class of vulnerability.
The business impact scales with the number of objects exposed. A single BOLA finding on an endpoint like /api/invoices/{id} is not one vulnerability — it is potentially every invoice in the tenant database, which is why remediation timelines and disclosure obligations differ from a typical XSS finding.
How to Test API1:2023 Broken Object Level Authorization
Testing BOLA is a manual, identity-driven process. The steps below reflect the API penetration testing methodology used across fintech, SaaS, and healthcare engagements.
- Map every object-referencing endpoint. Pull the full API surface from the OpenAPI/Swagger spec, Postman collection, or traffic capture. Flag every endpoint with a path parameter, query parameter, or body field that references an object ID:
/orders/{id},/users/{userId}/documents,/api/v1/claims?claimId=. - Provision at least two low-privilege accounts. BOLA cannot be tested from a single identity. Create Account A and Account B in the same role tier, and ideally a third account in a different tenant if the application is multi-tenant.
- Establish a baseline. Authenticate as Account A, request an object that belongs to Account A, and record the response: status code, body structure, and any object metadata returned.
- Swap the identifier. Using Account A's session token, request the same endpoint but substitute Account B's object ID. A secure API returns 403/404. A vulnerable API returns 200 with Account B's data.
- Test every HTTP verb, not just GET. BOLA on PUT, PATCH, and DELETE is more severe than BOLA on GET because it allows tampering or destruction of another user's data, not just disclosure.
- Test indirect object references. Some APIs expose the object ID only inside a nested response (an invoice referencing an internal account ID). Extract that ID and test it directly against the endpoint even if the UI never surfaces it.
- Test batch and export endpoints separately. Bulk endpoints (
/export,/reports/{id}/download) often skip the per-object authorization check applied to single-record endpoints. - Repeat across roles and tenants. Run the same test matrix for admin-to-user, user-to-admin, and cross-tenant combinations. A finding at one privilege boundary does not confirm the others are safe.
- Capture evidence for every test case. Screenshot or log the request, response, and identity used. Assessors and auditors require reproducible evidence, not a narrative summary.
- Validate the fix and retest. After remediation, retest with the same identifiers to confirm the authorization check now correctly rejects cross-object access, and confirm the fix did not introduce a regression on legitimate same-owner requests.
BOLA Test Matrix Example
Same-owner GET
- Identity Used: Account A
- Object Owner: Account A
- Expected Result: 200, own data
- Vulnerable If: N/A (baseline)
Cross-owner GET
- Identity Used: Account A
- Object Owner: Account B
- Expected Result: 403/404
- Vulnerable If: 200 with Account B data
Cross-owner PATCH
- Identity Used: Account A
- Object Owner: Account B
- Expected Result: 403/404
- Vulnerable If: 200, object modified
Cross-tenant GET
- Identity Used: Tenant 1 user
- Object Owner: Tenant 2 object
- Expected Result: 403/404
- Vulnerable If: 200, cross-tenant data returned
Admin-role bypass
- Identity Used: Standard user
- Object Owner: Admin-only object
- Expected Result: 403
- Vulnerable If: 200, privileged data returned
Bulk export
- Identity Used: Account A
- Object Owner: All tenant objects
- Expected Result: Only A's objects
- Vulnerable If: Full dataset returned
Why Broken Object Level Authorization Occurs
BOLA is an architecture and code-review gap, not a single misconfigured setting. The recurring root causes across engagements:
- Authentication is confused with authorization. Developers verify the token is valid but never check whether the token's owner matches the requested object's owner.
- Object IDs are sequential or guessable. Auto-incrementing integer IDs make enumeration trivial once one valid ID is known.
- Authorization logic lives in the frontend, not the API. The UI hides objects the user should not see, but the backend endpoint accepts any ID passed to it.
- Microservices skip re-validation. A gateway authenticates the request once, then internal services trust that authentication was sufficient and skip per-object checks downstream.
- Rapid API expansion outpaces access-control review. New endpoints get shipped faster than security review cycles, especially in AI-assisted and vibe-coded development pipelines.
- Multi-tenant isolation is assumed, not enforced. Tenant ID is often passed as a client-supplied parameter instead of derived server-side from the authenticated session.
Manual Testing vs Automated Scanning for BOLA
DAST/automated scanners
- What It Catches: Missing headers, known CVEs, basic injection
- What It Misses: Ownership logic, business context, multi-step object chains
- Best For: Baseline coverage between assessments
Manual penetration testing
- What It Catches: Cross-account object access, nested ID exposure, batch endpoint gaps
- What It Misses: Nothing structural — limited by tester time and scope
- Best For: Compliance-grade evidence, high-risk APIs
Hacker-led / agentic testing
- What It Catches: Chained BOLA-to-privilege-escalation paths, business logic abuse
- What It Misses: N/A when paired with manual validation
- Best For: Fintech, healthcare, and regulated SaaS APIs
Scanners cannot determine that Account B's invoice ID does not belong to Account A — that requires two authenticated identities and a human decision about what "unauthorized" means in context. This is why the OWASP broken access control testing guide treats BOLA as a subset of the broader access control category that automated tools structurally cannot validate.
How BOLA Testing Maps to Compliance Frameworks
PCI DSS 4.0
- What Assessors Check: Access controls over cardholder data, Requirement 6.4/8.3
- Testing Implication: API tests must confirm no cross-account access to payment or cardholder records
SOC 2 Type II
- What Assessors Check: Logical access controls (CC6 series)
- Testing Implication: Evidence of object-level authorization testing across the audit period, not a single point-in-time check
ISO 27001
- What Assessors Check: A.8.3 access restriction controls
- Testing Implication: Risk register must document API authorization testing scope and findings
HIPAA
- What Assessors Check: Minimum necessary access, ePHI safeguards
- Testing Implication: Cross-patient object access is a reportable finding, not a low-severity bug
NIST SP 800-53
- What Assessors Check: AC-3, AC-6 access enforcement
- Testing Implication: API test evidence supports control assessment for federal and FedRAMP boundaries
BOLA Testing Checklist
- Object-referencing endpoints mapped from spec or traffic capture
- Two or more low-privilege test identities provisioned
- GET, PUT, PATCH, DELETE all tested per endpoint
- Nested and indirect object IDs extracted and tested
- Batch/export endpoints tested separately from single-record endpoints
- Cross-tenant and cross-role combinations tested
- Evidence captured per test case (request, response, identity)
- Fix retested against the same identifiers post-remediation
Is BOLA the Same as IDOR?
BOLA and Insecure Direct Object Reference (IDOR) describe the same underlying flaw — an application returns or modifies an object based on a user-supplied identifier without verifying ownership. IDOR is the OWASP Web Top 10 term; BOLA is the API-specific term OWASP introduced in the API Security Top 10. In practice, testers use the same technique for both: swap the identifier, check the authorization outcome.
How Do Attackers Discover BOLA Vulnerabilities in the Wild?
Attackers discover BOLA by intercepting normal application traffic through a proxy, then systematically altering numeric or UUID-style identifiers while replaying the request with their own session token. Sequential IDs make this trivial; even UUIDs get discovered when they leak through other endpoints, error messages, or export features. This is the exact workflow security researchers document in PortSwigger's Web Security Academy material on insecure direct object references, and it requires no specialized tooling beyond a proxy and patience.
What Tools Support BOLA Testing?
Burp Suite (with the Autorize or Auth Analyzer extensions), Postman with scripted identity-swap collections, and OWASP ZAP support the mechanical part of BOLA testing — replaying requests under a second identity. None of these tools determine which responses are actually unauthorized; that judgment call requires a tester who understands the application's data model. This is the core reason API1:2023 findings correlate with manual assessment depth rather than scan frequency.
One Last Thing
The most damaging BOLA findings rarely sit on the endpoint testers check first. They surface on secondary features — export tools, webhook payloads, admin impersonation views, and audit log viewers — that were built after the core API's authorization model was already reviewed and approved. Any endpoint added after the original security review deserves its own object-level authorization test, not an assumption that it inherits the same protections.
FAQ
What is API1:2023 Broken Object Level Authorization?
API1:2023 is the OWASP API Security Top 10 category for cases where an API fails to verify that an authenticated user actually owns the object they are requesting, modifying, or deleting. It is ranked #1 on the 2023 list and remains the most common API finding reported in 2026 assessments.
How is BOLA different from broken function level authorization (API5:2023)?
BOLA concerns access to a specific object instance (this user's invoice), while broken function level authorization concerns access to an entire function or endpoint (an admin-only action). A single API can have both flaws independently.
Can automated scanners find BOLA vulnerabilities?
Automated scanners can flag missing authentication but cannot reliably determine object ownership without business context, so they miss most true BOLA cases. Manual testing with multiple authenticated identities is required to validate this class of finding.
How often should BOLA testing be performed?
BOLA testing should run with every API penetration test cycle and after any release that adds new object-referencing endpoints, since new features are the most common source of fresh BOLA gaps in 2026 release cadences.
Does BOLA testing require production access?
No. BOLA testing should be performed in a staging or pre-production environment with realistic multi-tenant test data, since production testing risks exposing real customer records during the assessment itself.
What severity rating does a BOLA finding typically receive?
Most BOLA findings on endpoints exposing PII, financial data, or health records are rated High or Critical under CVSS, since the impact scales to every object in the affected dataset rather than a single record.
Is GraphQL affected by BOLA?
Yes. GraphQL resolvers that accept a node ID or object reference without server-side ownership checks are just as vulnerable to BOLA as REST endpoints, and nested query structures can make the flaw harder to spot during code review.
How does BOLA testing fit into a PCI DSS penetration test?
PCI DSS 4.0 requires access control testing over any API touching the cardholder data environment, and BOLA test cases are the standard method assessors expect to see evidence of cross-account payment object access being blocked.
What is the fix for a confirmed BOLA vulnerability?
The fix is to derive the object owner server-side from the authenticated session and compare it against the requested object's owner on every request, rather than trusting any client-supplied identifier as sufficient proof of access rights.
Should BOLA testing include third-party and partner APIs?
Yes, any API that accepts an object identifier from an external partner or third-party integration should be included, since partner-facing endpoints are frequently built with looser authorization assumptions than internal APIs.
BOLA testing is not a one-time checklist item — it is a recurring validation exercise that has to keep pace with every new object-returning endpoint an engineering team ships. A penetration testing program that treats API1:2023 as a standing test category, evaluated against every role and tenant boundary at every release, catches the authorization gaps that automated tooling structurally cannot.
Get your API tested for BOLA
Schedule a hacker-led API penetration test focused on object-level authorization gaps.
Related Guides
Tejas K. Dhokane is a marketing associate at AppSecure Security, driving initiatives across strategy, communication, and brand positioning. He works closely with security and engineering teams to translate technical depth into clear value propositions, build campaigns that resonate with CISOs and risk leaders, and strengthen AppSecure’s presence across digital channels. His work spans content, GTM, messaging architecture, and narrative development supporting AppSecure’s mission to bring disciplined, expert-led security testing to global enterprises.
.webp)
