API Access Control Vulnerabilities: Complete Testing Guide

A user changes order_id=1001 to order_id=1002 in an API request and receives another customer's shipping address and payment details. The API authenticated the user but never checked whether that user owned the requested order.

An access control vulnerability like that is not an edge case. Broken access control holds #1 in both the OWASP Top 10 and the Open Web Application Security Project (OWASP) API Security Top 10, appearing as API1:2023 (Broken Object Level Authorization) and API5:2023 (Broken Function Level Authorization). For a breakdown of all ten categories, see our guide to the 2023 OWASP API Top 10.

The Salt Labs State of API Security Report found that 95% of organizations experienced API security issues, with BOLA accounting for roughly 40% of all API attacks.

What Is Broken Access Control in APIs?

Access control determines what an authenticated user can do. Authentication answers "who are you?" while authorization answers "what are you allowed to access?" A broken access control vulnerability occurs when an API fails to enforce authorization, letting users read, modify, or delete resources belonging to others.

APIs are fundamentally different from web applications because every endpoint is directly callable through tools like cURL, Postman, or automated scripts. Attackers do not need a browser to manipulate requests. 

Here is a broken access control example in a REST API:

GET /api/v1/users/8821/orders HTTP/1.1

Authorization: Bearer <user_A_token>

‍

User A is authenticated. The access control vulnerability exists when User A changes the ID to 8822, and the API returns User B's orders without verifying ownership.

Two Types of API Access Control Vulnerabilities

Access control problems in cybersecurity span a wide range, but APIs face two dominant patterns from the OWASP API Security Top 10, each targeting a different authorization dimension. For deeper coverage, see our guides on BOLA and BFLA.

Broken Object Level Authorization (BOLA, API1:2023) occurs when a user accesses data objects belonging to another user by manipulating identifiers. The API authenticates the caller but does not validate ownership, enabling horizontal privilege escalation.

Broken access control examples of BOLA include:

• Changing /api/orders/1001 to /api/orders/1002 to read another user's order details
• Enumerating sequential user IDs to harvest thousands of customer records in a loop
• Modifying an account_id in a JSON body to access a different account's balance

BOLA is especially dangerous because it requires no special privileges. Any authenticated user with a valid token can attempt the attack simply by guessing or incrementing object identifiers.

Broken Function Level Authorization (BFLA, API5:2023) occurs when a regular user calls admin-only API functions. The API grants access based on authentication alone without checking roles, enabling vertical privilege escalation. Common BFLA examples include:

• A standard user calling PUT /api/users/self/role to escalate their own privileges to admin
• Accessing DELETE /api/admin/users/8822 without admin credentials
• Calling undocumented internal endpoints found through API discovery or traffic interception

Real-World API Access Control Breaches

Access control issues have caused some of the largest API breaches. Here are incidents where broken access control led to massive data exposure:

Optus (2022)

An unauthenticated API with sequential user IDs exposed 9.8 million customer records at Australia's second-largest telecom. The API required no credentials to connect, and all customer identifiers were incremented by one (5567, 5568, 5569). Attackers wrote a simple script that looped through every ID, extracting names, dates of birth, phone numbers, and passport details. Australia's Cybersecurity Minister called the breach a result of "basically leaving the window open."

Coinbase (2022)

A missing logic validation in Coinbase's Retail Brokerage API allowed a researcher to trade using a mismatched source account. The API checked whether the source account had sufficient balance, but never verified whether the source account matched the asset being traded. The researcher submitted an Ethereum wallet as the source for a Bitcoin sell order, and the trade executed on the live order book. Coinbase patched the flaw within hours and paid a $250,000 bounty, the largest in company history.

T-Mobile (2023)

A threat actor exploited a single API to extract data from 37 million postpaid and prepaid customer accounts, including names, billing addresses, emails, and phone numbers. The attack ran undetected for 41 days, from November 25, 2022, to January 5, 2023, when T-Mobile's security team finally identified the unauthorized access. T-Mobile's SEC filing confirmed the data was obtained through the API "without authorization," marking the company's eighth disclosed breach since 2018.

Each breach followed the same pattern: the API confirmed identity but failed to confirm permission.

How to Test for API Access Control Vulnerabilities

Standard Dynamic Application Security Testing (DAST) scanners miss access control flaws because they test with a single authenticated session. Detecting BOLA and BFLA requires multiple users attempting cross-user and cross-role access. Our API penetration testing checklist covers the full workflow, but here are the key methods:

Object-level authorization testing (BOLA)

Authenticate as User A, capture a request containing an object ID, then replay the exact same request using User B's object ID while keeping User A's token. A 200 OK response with User B's data confirms a BOLA flaw.

• Swap user IDs, order IDs, and account IDs across authenticated sessions
• Enumerate a sequential identity test for mass data exposure
• Confirm 403 Forbidden or 404 Not Found for unauthorized objects
• Repeat tests using POST, PUT, and DELETE, not just GET, since write operations are often less protected

Function-level authorization testing (BFLA)

Authenticate as a regular user and systematically call every endpoint reserved for admin roles. Many APIs restrict admin functions in the UI but leave them unprotected at the API layer.

• Call admin endpoints like /api/admin/users with a standard user token and check for 200 responses.
• Switch HTTP methods on existing endpoints (e.g., send DELETE to a GET-only resource)
• Access undocumented endpoints discovered through OpenAPI specs or traffic interception
• Attempt to modify role or permission fields via PATCH requests to profile endpoints.

Automated API security testing

Manual cross-user testing is effective but does not scale across hundreds of endpoints. Purpose-built API security testing platforms maintain multiple authenticated sessions and automatically replay every request across user contexts. Automated platforms parse API specifications, identify endpoints accepting object identifiers, and generate targeted BOLA and BFLA attack scenarios with proof-of-exploitation details.

How to Prevent Broken Access Control in APIs

Preventing access control problems requires enforcement at the code level, not just the API gateway. Gateways handle authentication and rate limiting, but cannot validate whether User A owns Order 1002. 

Pair these strategies with API authentication and authorization best practices:

1. Enforce object-level authorization on every request

Every endpoint accepting an object identifier must validate that the authenticated user owns or has permission to access that specific object. Implement this server-side as reusable middleware that runs before business logic executes:

def get_order(request, order_id):

    order = db.get_order(order_id)

    if order.user_id != request.user.id:

        return Response(status=403)

    return Response(order.to_dict())

‍

Centralizing authorization in middleware ensures consistent enforcement. When logic is scattered across individual handlers, new endpoints inevitably ship without checks.

2. Layer RBAC with attribute-based access control

Use Role-Based Access Control (RBAC) to restrict endpoint access by role, and add Attribute-Based Access Control (ABAC) to enforce object ownership. RBAC alone is insufficient because a "viewer" role may access /api/orders, but RBAC says nothing about which orders that viewer can see. ABAC adds the ownership check.

3. Use non-predictable object identifiers

Replace sequential IDs with UUIDs or hashed identifiers. Sequential IDs like 1001, 1002, 1003 make enumeration trivial, while UUIDs force attackers to guess from an astronomically large space. Non-predictable IDs are not a substitute for authorization checks, but they eliminate the easiest attack vector.

4. Deny by default

Configure every endpoint to reject access unless an explicit rule grants it. New endpoints added during development are automatically protected before developers write authorization logic. Many access control issues originate from endpoints "temporarily" left open and never locked down.

5. Integrate continuous access control testing in CI/CD

 Authorization logic changes with every release. A new endpoint or refactored service can silently break access control that worked yesterday. Running automated API security testing in a Continuous Integration/Continuous Deployment (CI/CD) pipeline catches regressions with every build.

Close the Access Gaps Before Attackers Walk Through

Broken access control remains the most exploited API vulnerability because authorization logic is complex and easy to overlook. Object-level checks, deny-by-default policies, and continuous testing close those gaps.

APIsec tests every endpoint for BOLA, BFLA, and the full OWASP API Top 10. 

Start a free scan and uncover access control flaws your current tools miss.

FAQs

What is the difference between BOLA and BFLA?

BOLA allows users to access data belonging to other users (horizontal escalation), while BFLA allows users to execute functions reserved for privileged roles (vertical escalation). Both are broken access control vulnerabilities.

Why do automated scanners miss access control vulnerabilities?

Standard scanners test with a single session. Detecting BOLA and BFLA requires multiple authenticated users attempting cross-user and cross-role access, which only context-aware testing platforms perform.

What is the most common broken access control example in APIs?

Manipulating object IDs in API requests to access another user's data is the most frequent pattern, responsible for breaches at Optus, Coinbase, and T-Mobile.

How does OWASP broken access control map to the API Security Top 10?

OWASP broken access control (A01:2021) maps to API1:2023 (BOLA), API3:2023 (Broken Object Property Level Authorization), and API5:2023 (BFLA) in the API-specific list.

Can API gateways prevent broken access control?

Gateways enforce authentication and rate limiting, but cannot validate object-level ownership. Preventing BOLA and BFLA requires authorization logic in application code, not the gateway layer.