Skip to content
Clear Infosec

API Penetration Testing Methodology: OWASP API Security Top 10

API penetration testing focuses on authorization and authentication flaws that scanners miss, using the OWASP API Security Top 10 as the reference model, with Broken Object Level Authorization (BOLA) as the most common and highest-impact class of issue.

By Clear Infosec Last reviewed: 2026-08-19 Aligned to OWASP API Security Top 10, OWASP, PTES

Why APIs need dedicated testing

APIs expose application logic and data directly, without the browser-rendered UI that constrains a human user. Many API weaknesses are authorization flaws that only appear when you manipulate identifiers, tokens, and object references, so traditional web scanners frequently miss them.

The reference model is the OWASP API Security Top 10 (https://owasp.org/API-Security/). It is the standard checklist for scoping and reporting API assessments.

Authentication testing

Authentication testing checks that identity is proven correctly and that tokens cannot be forged, replayed, or bypassed. For JWT-based APIs this includes verifying signature validation, rejecting the none algorithm, and confirming that expiry and audience claims are enforced.

Broken Authentication (API2 in the OWASP list) covers weak or missing credential controls, flawed token generation, and endpoints that skip authentication entirely.

  • Test for missing signature verification and algorithm-confusion on JWTs.
  • Check credential-stuffing and brute-force protections on login and token endpoints.
  • Confirm tokens are invalidated on logout and password change.

Authorization testing: BOLA and function-level access

Broken Object Level Authorization (BOLA, API1) is the most prevalent and damaging API flaw. It occurs when an endpoint returns or modifies an object based on an identifier in the request without checking that the caller owns or may access that object.

Testing is systematic: authenticate as a low-privilege user, then substitute object identifiers belonging to other users or tenants and observe whether access is granted. Broken Function Level Authorization (API5) is the parallel test for administrative or privileged functions reachable by ordinary accounts.

  • Enumerate every endpoint that accepts an ID, GUID, or reference.
  • Compare responses across two separate test accounts to prove cross-tenant access.
  • Test hidden and undocumented methods; a GET may be authorized while the PUT or DELETE is not.

Resource, input, and inventory issues

Unrestricted Resource Consumption (API4) covers missing rate limiting and pagination controls that enable denial of service or cost amplification. Verify that per-client throttling exists and that large or unbounded queries are rejected.

Improper Inventory Management (API9) and Broken Object Property Level Authorization (API3, which includes mass assignment and excessive data exposure) round out common findings. Deprecated or undocumented API versions often lack the controls present on current endpoints.

  • Test mass assignment by adding privileged fields such as role or isAdmin to request bodies.
  • Look for excessive data exposure where the API returns more fields than the client displays.
  • Enumerate older API versions and non-production hosts that may still be reachable.

Tooling and reporting

Effective API testing pairs proxy interception tools with the API specification. An OpenAPI or GraphQL schema accelerates coverage by revealing every route, parameter, and type, which is why a grey-box approach with documentation is usually more efficient than pure black box.

Findings are reported per endpoint with the OWASP API category, reproduction requests, the two-account evidence for authorization flaws, and remediation that fixes the server-side check rather than the client.

Related

FAQ

What is BOLA and why is it ranked first?

Broken Object Level Authorization is a missing server-side ownership check on object references. It is ranked first in the OWASP API Security Top 10 because it is extremely common, easy to exploit by changing an identifier, and typically exposes other users' or tenants' data directly.

Can automated scanners find API authorization flaws?

Generally no. Authorization flaws like BOLA depend on business context and object ownership, which scanners cannot infer. They require manual testing with multiple accounts to confirm that one user can reach another user's objects.

Does the OWASP API Security Top 10 cover GraphQL?

Yes. The categories are transport-agnostic and apply to REST, GraphQL, and gRPC. GraphQL adds specific concerns such as query depth and complexity that map to Unrestricted Resource Consumption (API4).

Want this applied to your environment? Request a scoping call.