API Penetration Testing Methodology and the OWASP API Top 10

Here is the opinion that shapes everything below: on an API, injection is a secondary concern and authorization is the whole game. The OWASP API Security Top 10 (2023) agrees, putting Broken Object Level Authorization at number one and filling two of its top five slots with access-control failures. Gartner predicted years ago that APIs would become the most frequent attack vector for enterprise web apps, and the 2023 list is what that prediction looks like once it lands in a report.

A methodology is what stops your coverage from depending on memory or mood. This guide lays out the five phases we run on every engagement, maps a concrete test to each of the ten OWASP API risks, then walks a real chain end to end: a BFLA that leaks user IDs, a BOLA that reads them, and a mass-assignment write that escalates the account. You will see the requests, the cracked token, a findings table, and the exact config that closes each gap.

What is an API penetration testing methodology?

It is a fixed sequence of phases that takes you from zero knowledge to a categorized findings report, applied identically to every API so nothing is skipped. The difference between a methodology and random fuzzing is that a methodology guarantees you tested authorization on every object endpoint, not just the ones you happened to remember.

The five phases form a pipeline where each one hands structured output to the next:

1. Reconnaissance: enumerate endpoints, versions, and parameters.
2. Endpoint analysis: record, per route, which object it touches and what role should reach it.
3. Authorization testing: BOLA and BFLA across multiple accounts and roles.
4. Exploitation: injection, mass assignment, logic abuse, resource exhaustion, chaining.
5. Reporting: map each finding to an OWASP API category with CVSS and reproduction.

This mirrors a classic penetration testing methodology but reorders the work around the API's weakest point. A web-app methodology front-loads injection and XSS; on an API those are secondary. The endpoint-analysis phase exists precisely to build the route-to-role table that authorization testing consumes, and skipping it is why ad-hoc tests miss the obvious cross-tenant read.

The OWASP API Top 10 is the backbone, not the whole skeleton

Anchor the methodology to the OWASP API Security Top 10 because it is the only widely accepted taxonomy built specifically for API risks, and it reflects how APIs actually get breached rather than how web pages do. The 2023 edition restructured the list to emphasize authorization, merged the old excessive-data-exposure and mass-assignment entries into BOPLA (API3), and added Unsafe Consumption of APIs (API10) that the 2019 list missed.

Anchoring buys you three things: complete coverage (you test all ten), a shared language with developers, and a clean mapping into compliance frameworks. The table below maps each risk to the concrete test you run on a captured request. But the Top 10 is a backbone, not the full skeleton, because it does not explicitly cover business-logic and chaining attacks. Those get a dedicated exploitation pass, covered later. It also pairs naturally with the broader OWASP Web Security Testing Guide when an API sits behind a web front end.

How do you test broken authentication (API2)?

Broken authentication gets its own pass against the token, because a token the server mis-validates is a master key into every other category. JWTs fail predictably, and the discipline of the methodology is running the same battery against every authentication surface, not just the login you happened to notice.

The repeatable battery is alg:none acceptance, a tampered signature byte that still returns 200, a kid header pointed at a path or SQL fragment for key confusion, an HMAC secret weak enough to crack offline, plus expiry and reuse. The crack is mechanical once you capture a token:

$ hashcat -a 0 -m 16500 token.jwt rockyou.txt   # -m 16500 = JWT mode

eyJhbGciOiJIUzI1NiJ9...<snip>:companyname2020   # <- signing secret recovered
Status...........: Cracked

With the recovered secret you sign a token carrying "role":"admin" and walk straight into the admin functions recon found. The fix is not 'use a stronger secret' alone: validate the alg against a fixed allowlist, reject none outright, and move to RS256 so the verification key is not the signing key.

How do you chain a BFLA into a BOLA into full account takeover?

You exploit BFLA by invoking an admin-only function with a low-privilege token, usually after recon revealed the admin route, then you use what it leaks to drive the next step. The function-level check is missing or done client-side, so the server runs the action. Here is the telltale: the admin UI fetches a user list at /api/v2/admin/users, and a standard user token should get a 403.

GET /api/v2/admin/users?limit=500 HTTP/1.1
Host: app.example.com
Authorization: Bearer <standard-user-token>   # not an admin

--- response ---
HTTP/1.1 200 OK                               # <- BFLA: should be 403
[ {"id":1,"email":"ceo@example.com","role":"admin"},
  {"id":2,"email":"...","role":"user"}, ... 498 more ]

A 200 with the full user list is the BFLA: the gateway authenticated the token but never checked the role on the route. Now you chain. That list leaks every user ID, which feeds a BOLA against /api/v2/users/{id}, and a writable admin mutation lets you flip your own role to admin:

PATCH /api/v2/users/88 HTTP/1.1
Authorization: Bearer <standard-user-token>
Content-Type: application/json

{ "role": "admin" }                           # <- mass assignment

--- response ---
HTTP/1.1 200 OK
{ "id": 88, "role": "admin" }                 # <- escalation confirmed

BFLA leaks the IDs, BOLA reads them, mass assignment escalates you. That multi-step reasoning is exactly what a scanner never reconstructs, and it is where an API pentest earns its keep.

Business logic lives outside the Top 10's neat boxes

Logic flaws do not fit the Top 10's categories, so the methodology adds a dedicated exploitation pass for sequence, state, and value abuse. After the categorized tests, walk each stateful workflow and ask what assumption the developer made that you can break.

• Tamper with values the server should recompute: price, quantity, currency, discount. See payment tampering for the full pattern.
• Break sequence: confirm an order without paying, or apply a coupon after checkout.
• Race shared state: two concurrent withdrawals against one balance, or two redemptions of one token, landed inside the same transaction window with a single-packet attack.
• Chain findings, as above, into a takeover path.

On a recent assessment of a healthcare scheduling API, the documented surface passed every categorized test, but the logic pass found that the appointment-cancel flow refunded a copay without validating the original charge state. Two concurrent cancels refunded the same payment twice. Chaining and logic are where API pentests deliver outsized value, and exactly the multi-step reasoning that agentic pentesting can now run continuously rather than once a year.

How do you report and remediate API findings?

Report each finding against its OWASP API category, score it with CVSS, and prove it with a paired request and response. Prioritize by exploitability: a BOLA on a sequential integer ID is trivially scriptable and outranks a theoretical issue gated behind admin auth. The findings table below is the shape of a real report excerpt.

For each finding include the category, CVSS vector, affected endpoint, the exact reproduction request, the observed response, and a remediation that names the control. Remediation must be specific:

• BOLA (API1): enforce an object-level ownership check inside the resolver or controller, not at the gateway.
• BOPLA (API3): allow-list writable properties instead of binding the whole body.
• Broken auth (API2): validate the JWT alg against a fixed allowlist and reject none.
• Resource consumption (API4): rate-limit per identity rather than per IP.

A clean OWASP mapping also makes the report usable by developers. See our guide on API pentesting tools for what to capture evidence with, and the checklist for the per-endpoint working list.

Frequently asked questions

Sources and references

• OWASP API Security Top 10 (2023)
• OWASP API Security Project
• Gartner: API Security best practices