Mastering API pentesting: Part 1 - recon, authentication, authorization
BOLA (broken object-level authorization) is still #1 on the OWASP API Top 10 - same as 2019, same as 2023. The first 20% of an API engagement is inventory, auth mapping, and authorization probing. This is how we run it.
What changes when you test an API vs a web app
Web app testing is about pages, forms, and stateful flows. API testing is about endpoints, schemas, and contracts. Different mental model, different tooling, same end goal: find the failure modes before someone else does.
The OWASP API Security Top 10 (current edition: 2023) is the canonical methodology reference. It replaces the 2019 edition; the headline change is that BOLA stayed at #1 and BFLA moved from #5 to #5 with expanded scope.
The mental model shift
| Dimension | Web app testing | API testing |
|---|---|---|
| Unit of testing | Pages / flows | Endpoints / schemas |
| State | Browser session | Token / contract |
| Tooling | Burp + browser | Burp + Postman + custom |
| Common findings | XSS, CSRF, auth flow | BOLA, mass assignment, BFLA |
| Coverage measure | Page coverage | Endpoint × verb × role |
| OWASP reference | Top 10 (2021) | API Top 10 (2023) |
Part 1: reconnaissance and authentication
This first part covers what we do in the opening 20% of an engagement.
Inventory (API9:2023 - Improper Inventory Management)
Pull every API definition we can find - OpenAPI/Swagger specs, WSDL files, Postman collections in public repositories, network captures from the legitimate client, WAF and API-gateway logs. The gap between "documented endpoints" and "endpoints in production" is where the interesting findings live - and OWASP API9 ranks this risk on its own.
Authentication mapping (API2:2023 - Broken Authentication)
For each endpoint, classify: auth required (yes/no/inconsistent), mechanism (Bearer/Basic/Cookie/Custom), token issuance flow, token lifetime + refresh, token scope encoding. Inconsistency between endpoints is the single most useful signal.
Authorization probing (API1 + API5:2023)
For each authenticated endpoint: can I access another user's resources with my token (BOLA)? Can I read/write resources my role shouldn't see (BFLA)? Does authorization happen at the right layer - controller, middleware, or DB? BOLA still lives here - and remained the #1 OWASP API risk in the 2023 edition.
Sources we mine during inventory
Documented &neq; production. We've seen production APIs where 5% of endpoints had no auth at all - usually internal-only that leaked through a public gateway. The OpenAPI spec didn't include them. The mobile binary did. This is exactly the failure mode OWASP API9:2023 was written to address.
Authorization findings we catalogue (mapped to OWASP API 2023)
# Example BOLA probe - swap an account ID we don't own
GET /api/v2/accounts/843/orders HTTP/1.1
Authorization: Bearer <our-token>
Host: api.target.tld
# Expected:
HTTP/1.1 403 Forbidden
# Observed (the BOLA):
HTTP/1.1 200 OK
{"account_id": 843, "orders": [...]}
| OWASP API ID | Finding class | Frequency on our engagements |
|---|---|---|
| API1:2023 | Broken object-level auth (BOLA) | 41% |
| API5:2023 | Broken function-level auth (BFLA) | 24% |
| API6:2023 | Unrestricted access to sensitive business flows | 18% |
| API3:2023 | Broken object property level authz (mass assignment) | 14% |
| API9:2023 | Improper inventory management | 22% |
BOLA is still our #1 API finding category. After OWASP highlighted it at #1 in both 2019 and 2023, broken object-level authorization keeps being the easiest critical we find on engagements.
- Staatse API engagement retrospective, 2024
Key takeaways
- The OWASP API Security Top 10 (2023) is the canonical methodology reference - use it as your engagement scaffolding.
- Inventory beats fuzzing - the endpoint you don't know about is the one with no auth. API9:2023 exists for this reason.
- BOLA / IDOR remains the highest-volume critical finding on every API engagement - same as 2019, same as 2023.
- Authorization should sit at one layer, consistently - middleware, not "wherever the dev remembered."
What's coming in Part 2
Business logic flaws (API6:2023), rate-limiting bypass (API4:2023), and GraphQL-specific attack surface. Read Part 2.
If your team is rolling out new APIs and wants a structured second-pass before launch, our web application security service covers REST and GraphQL.
References & further reading
- OWASPOWASP API Security Top 10 - 2023 edition
- OWASPAPI1:2023 - Broken Object Level Authorization (BOLA)
- OWASPAPI2:2023 - Broken Authentication
- OWASPAPI5:2023 - Broken Function Level Authorization (BFLA)
- PortSwiggerWeb Security Academy - API testing labs
- NISTSP 800-204: Security strategies for microservices-based application systems
- OWASPWeb Security Testing Guide (WSTG) - API testing chapter