API Penetration Testing That Finds BOLA With ID Swaps: OWASP Aligned

API penetration testing simulates real attacks against an API to uncover exploitable authentication, authorization, injection, SSRF, and business-logic flaws before an attacker finds them first. Authorization failures, particularly broken object-level authorization (BOLA), rank as the top risk category in the OWASP API Security Top 10. The strongest engagements pair automated discovery with hands-on manual verification, and success looks like a reproducible proof of concept tied to clear remediation steps, not a scanner printout.

---

TL;DR:

• API penetration tests should be conducted before production releases, during compliance audits, before third-party onboarding, and after security incidents.
• Building a comprehensive endpoint inventory requires both passive discovery, such as spec analysis and JavaScript scraping, and active brute forcing and fuzzing techniques.
• Confirming vulnerabilities like broken object-level authorization demands cross-user request comparisons with raw proof, not scanner alerts alone.
• Testing should include injection across REST and GraphQL, rate limits, business logic abuses, and SSRF, especially in cloud environments with internal metadata endpoints.
• Manual verification remains essential for validating multi-step exploits and reducing false positives identified by automated tools.

---

Table of Contents

• When Should You Run an API Penetration Test?
• How Do You Prepare a Lab for API Testing?
• How Do You Discover Hidden and Undocumented Endpoints?
• Testing Authentication and Authorization: Where BOLA Lives
• Injection Testing Across REST and GraphQL Payloads
• Testing Business Logic, Rate Limits, and SSRF
• What's Different About Testing GraphQL and gRPC APIs?
• Should You Rely on Automated Tools or Manual Testing?
• What Belongs in an API Pentest Report?
• An Earthshaker Security Practitioner's View on API Testing
• Get an API Penetration Test Backed by Manual Verification
• Sources
• FAQ

When Should You Run an API Penetration Test?

Four moments consistently trigger a test: before a production release, to satisfy a compliance mandate like PCI DSS or SOC 2, before onboarding a third-party integration partner, and after a suspected incident. Each scenario shapes scope differently, so define it before the engagement starts.

A workable scope checklist covers, especially when handling sensitive data such as health records, as outlined in the security questionnaire for healthcare software:

• Target environments (staging vs. production) and which endpoints are in bounds
• Authentication modes to test (API keys, OAuth, JWT, session cookies)
• Data sensitivity classes handled by the API (PII, payment data, health records)
• Explicit sign-off on any destructive checks, such as mass data creation or deletion

Most commercial engagements use a gray-box model. Testers get partial documentation and at least one valid credential, which mirrors what a real attacker with a leaked token or compromised account would have. Safe-mode controls, including dry-run flags, request throttling, and a rollback plan for test data, keep aggressive checks from taking down a production system mid-test.

How Do You Prepare a Lab for API Testing?

Preparation determines how much of the engagement window gets spent testing versus fumbling with setup. Gather every specification artifact you can find first: OpenAPI/Swagger files, Postman collections, and GraphQL SDL schemas. Import all of it into your tooling before touching a single endpoint.

1. Capture baseline traffic through an intercepting proxy like Burp Suite or OWASP ZAP to understand normal request and response shapes.
2. Provision at least two distinct test identities, since cross-user comparisons are what expose object-level authorization flaws later.
3. Enable safe-mode or dry-run flags for any check capable of altering data, and document a rollback procedure before running it.
4. Set up evidence storage: raw request/response pairs, packet captures, and timestamped logs for every finding you plan to report.

Pro Tip: Name your test identities something obvious, like user_a and user_b, in every saved request. Six hours into a test, you will not remember which token belonged to which account, and mislabeled evidence undermines an otherwise solid finding.

How Do You Discover Hidden and Undocumented Endpoints?

An endpoint inventory built only from official documentation is almost always incomplete. Passive reconnaissance fills the gaps: pull OpenAPI specs, scan public documentation, extract routes from client-side JavaScript bundles, check the Wayback Machine for retired API versions, and run Git dorking against public repositories for leaked internal endpoints.

Active methods do the rest of the work:

• Directory and path bruteforcing against common naming patterns (/v1/, /internal/, /admin/)
• Parameter mining by fuzzing query strings and JSON body fields
• Spidering authenticated sessions through a proxy to catch endpoints only reachable after login
• AST-based or regex extraction of API calls buried in minified JavaScript

The OWASP Web Security Testing Guide's API reconnaissance chapter treats this phase as foundational. For good reason, undocumented or deprecated endpoints frequently run older code with weaker access controls than the current version. Keep a running inventory across every API version you find, and flag anything that looks like a shadow endpoint the current team may not even know exists.

Testing Authentication and Authorization: Where BOLA Lives

Authentication checks come first but rarely produce the highest-impact findings. Look at token lifecycle handling (does a logged-out token still work?), JWT algorithm confusion and kid header manipulation, brute-force resistance on login endpoints, and whether MFA can be bypassed by hitting a legacy endpoint directly.

Authorization testing is where the real damage tends to surface. Three of the top five risk categories in the current OWASP API Security Top 10 relate directly to access control failures, not authentication weaknesses, which is why this phase deserves more engagement time than most testers give it.

A practical sequence looks like this:

1. Log in as user_a, capture a request that returns object data (an invoice, a profile, an order), and note the object ID.
2. Log in as user_b, replay the identical request but swap in user_a's object ID, and check whether the response returns data it should not.
3. Repeat the swap against write operations (PUT, PATCH, DELETE), not just reads, since BOLA on a write endpoint is far more damaging.
4. Test function-level privilege escalation by calling admin-only endpoints with a standard user token.
5. Attempt mass-assignment by adding unexpected fields ("role": "admin") to a legitimate update request.

Cross-user testing is what turns a suspicion into evidence. A single successful ID swap, captured as a raw HTTP pair with both requests side by side, is far more convincing to a development team than a narrative description of "potential BOLA." That pairing, not a vulnerability scanner's flag, is what separates a confirmed finding from a false positive.

Injection Testing Across REST and GraphQL Payloads

Injection risk in APIs hides in more places than a typical web form. Check the URL path itself, custom headers, the JSON body at every nesting level, and any XML payloads still accepted for legacy compatibility.

• Fuzz every parameter with SQL and NoSQL injection payloads, and use sqlmap against parameters that accept raw query fragments.
• For GraphQL, target field arguments and nested resolver inputs separately. Injection often survives in a resolver even after the top-level query is sanitized.
• Check for mass-assignment by submitting extra JSON fields the client normally never sends, and see if the API accepts and stores them.
• Review every response body for excessive data exposure. APIs frequently return full internal objects when the client only needed three fields.

Remediation almost always traces back to the same three fixes: parameterized queries instead of string concatenation, schema-driven input validation at the API gateway, and response minimization so the API only returns what the client actually needs.

Testing Business Logic, Rate Limits, and SSRF

Some of the costliest API flaws never trip a traditional vulnerability scanner because nothing is technically "broken." The logic just was not designed to resist abuse.

1. Send bursts of requests against rate-limited endpoints to see if the limit resets predictably or can be bypassed with rotating IPs or tokens.
2. Test business-flow abuse directly, such as scripted ticket scalping, fake-account creation at scale, or repeated coupon redemption.
3. Probe any endpoint that accepts a URL or webhook parameter for SSRF, including redirect-following behavior that could reach internal metadata endpoints.
4. Check for Unrestricted Resource Consumption by submitting oversized payloads or deeply nested requests that spike CPU or memory.

Pro Tip: Test SSRF with an internal cloud metadata address (169.254.169.254) whenever the target runs in a cloud environment. It is one of the fastest ways to prove real business impact from a flaw that looks minor on paper.

Short-term fixes are usually rate limits, strict URL allowlists, and request timeouts. Long-term fixes mean redesigning the flow so the business logic itself does not depend on client-side trust.

What's Different About Testing GraphQL and gRPC APIs?

GraphQL and gRPC carry attack surfaces a REST-focused checklist will miss entirely.

• Check whether introspection is enabled in production. If it is, an attacker gets a full schema map for free.
• Test query depth and complexity limits by submitting deeply nested queries designed to cause denial of service.
• Probe batching behavior, since some GraphQL implementations let attackers bundle hundreds of operations into a single request and dodge rate limiting.
• For gRPC, check whether server reflection is exposed publicly and whether the service accepts plaintext h2c connections instead of enforcing TLS.
• Import the GraphQL SDL or the protobuf schema directly into your tooling to generate deterministic, schema-accurate test cases rather than guessing field names.

The OWASP WSTG chapter on GraphQL testing covers resolver-level injection paths in more depth than most general API guides, and it is worth a direct read if GraphQL is a meaningful part of the target's surface.

Should You Rely on Automated Tools or Manual Testing?

Automated frameworks earn their place in the workflow, but only for what they are actually good at. Tools built around the OWASP API Security Testing Framework (ASTF) run structured test suites mapped to the OWASP Top 10, cover GraphQL, gRPC, and mutual TLS scenarios, and have been validated against intentionally vulnerable targets like crAPI and VAmPI.

What automation reliably misses is attacker-path chaining: the multi-step sequence where a low-severity information leak in one endpoint becomes the key to exploiting authorization on a completely different one. Automated scanners also cannot safely judge whether a state-changing request actually caused business harm, which is exactly the kind of verification a human tester has to perform by hand.

• Run automated sweeps first to cover the breadth of known vulnerability classes quickly.
• Triage every automated finding manually before it goes in a report.
• Chase business-logic and multi-step exploit chains by hand, since no scanner reasons about intent.
• Capture manual proof for every state-changing exploit before calling it confirmed.

Manual verification exists specifically to cut false positives and validate the exploit chains automation cannot reason through on its own, which is the core logic behind Earthshaker Security's hybrid approach to API and endpoint testing.

What Belongs in an API Pentest Report?

A report that just lists CVSS scores wastes the engagement. Development teams need enough context to reproduce, fix, and verify the fix without a follow-up call.

• Scope statement, tested endpoints, and the identities used during testing
• Full proof-of-concept request/response pairs for every confirmed finding
• Business impact framed in plain terms, alongside a CVSS or comparable severity score
• Step-by-step remediation guidance, split into short-term mitigation and long-term fix
• Retest criteria so the team knows exactly what "closed" looks like

Fix priority should follow risk, not convenience: authorization and data-exposure flaws close first, injection and business-logic issues next, and cosmetic header hardening last.

Finding Category	Typical Priority	Fix Type
BOLA / broken authorization	Critical, fix first	Long-term code change
Sensitive data exposure	Critical, fix first	Response schema change
Injection (SQL/NoSQL/XML)	High	Parameterized queries
Rate limiting / resource abuse	Medium	Gateway config, short-term
Missing security headers	Low	Config change

An Earthshaker Security Practitioner's View on API Testing

Most of the value in an API pentest comes from the findings a client can actually verify and act on, not the length of the report. We steer away from noisy checks that flag theoretical issues no attacker would chain into anything real, and instead reproduce the exact path an attacker would take. A typical pattern: swap an object ID between two authenticated test accounts, confirm the leak with a raw request pair, then hand the client a fix they can ship the same day.

— caleb

Get an API Penetration Test Backed by Manual Verification

Some API and endpoint testing services combine fast automated discovery with hand-verified exploitation, so every finding in a report is a confirmed flaw with a reproducible proof of concept, not scanner noise you have to triage yourself. Reports are written for both your engineering team and your non-technical stakeholders, and every engagement includes a retest to confirm the fix actually closed the gap.

Engagements come in a few shapes depending on how much ground you need covered. The Starter tier runs $1,000 as a one-off test, suited to a single API or a pre-release check. Teams that need continuous coverage typically move to the Retainer plan at $795 per month, and larger or custom scopes are priced at $450 per day. Full details on what each service includes, from API testing to configuration audits, are on the services page. Start by reviewing your pricing options and requesting a scope conversation with a tester directly, not a sales rep.

FAQ

What Are the Main HTTP Methods Tested in an API Pentest?

Testers exercise GET, POST, PUT, PATCH, and DELETE against every endpoint in scope, since authorization flaws often appear on one method but not another. A GET request might correctly block cross-user access while the PATCH endpoint for the same resource does not, which is why each method gets tested independently rather than assumed to inherit the same controls.

What Types of API Testing Should a Pentest Cover?

A thorough assessment covers functional testing, security testing, authentication and authorization testing, input validation and injection testing, business-logic testing, rate-limit and resource-consumption testing, and protocol-specific checks for GraphQL or gRPC where relevant. The OWASP API Security Top 10 is the standard reference for prioritizing which categories matter most.

What Tools Are Best for API Penetration Testing?

Burp Suite and OWASP ZAP handle traffic interception and manual manipulation, sqlmap targets injection points, and framework-based suites built on the OWASP API Security Testing Framework automate discovery and Top 10 test coverage. No single tool replaces manual verification of business-logic and authorization findings, which is why Earthshaker Security pairs automated sweeps with hands-on exploitation.

How Do You Perform API Testing Step by Step?

Start by defining scope and gathering specifications like OpenAPI files, then build an endpoint inventory through passive and active reconnaissance. From there, test authentication and authorization first, since that is where the highest-impact flaws typically live, followed by injection, business-logic, and rate-limiting checks, and close with a report containing reproducible proof of concept for every finding.

How Much Does an API Penetration Test Cost?

Pricing depends on scope and engagement length. Earthshaker Security's Starter tier is a $1,000 one-off test, the Retainer plan runs $795 per month for ongoing coverage, and custom scopes are billed at $450 per day.

Recommended

• Methodology
• Sample report