API penetration testing
Point Operator at your API. It parses your OpenAPI spec, tests every documented operation the way an attacker would, BOLA, BFLA, broken auth, mass assignment, injection, across user roles, and proves each finding with the exact request and response. Continuous, spec-driven, and safe against production.
Written by Berk Dusunur, Founder & CEO, Planck Proof · Updated September 2026
From spec to proven findings, in five steps
Setting up an API engagement takes minutes. You define the target and scope; the agent does the rest and streams its work live.
The host must be a domain you have verified, or a subdomain of it. Every request stays under this base, no other host is touched.
We parse the spec to list its operations. Only documented operations are tested.
Uncheck any operation you do not want tested. Include all · Exclude all
One bearer token per user type. Add two or more to unlock cross-account BOLA/BFLA testing (we send one role’s requests as another).
One per line, sent on every request
Scope: 37 operation(s) · 2 authenticated role(s) · agentic testing across every included operation.
Watch the agent test every operation
This is the operator console as a real API scan runs, parsing the spec, testing operations, chaining a leaked token, and confirming each finding.
What we test, the OWASP API Security Top 10
The agent maps to the 2023 OWASP API Security Top 10 and extends it with classic injection on every parameter your spec exposes. Our methodology also follows the guidance in NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment.
Broken Object Level Authorization
The number one API risk. We request other users’ objects by ID across roles to prove BOLA and IDOR reads and writes.
Broken Authentication
Forgeable or non-expiring tokens, weak JWT handling, and unauthenticated endpoints that should require a session.
Object Property Level Auth & Mass Assignment
Setting fields you should not be able to set, and reading properties that should never leave the server.
Unrestricted Resource Consumption
Missing rate limits and unbounded queries that let one caller exhaust or bill your infrastructure.
Broken Function Level Authorization
Calling admin or privileged functions as a lower-privileged role, tested by replaying one role’s requests as another.
Business flows, SSRF, misconfig, inventory
Sensitive business-flow abuse, server-side request forgery, misconfiguration, shadow and deprecated endpoints, and unsafe upstream consumption.
Aimed by recognized method, not improvisation
Operator's test library for this coverage is structured against the same published frameworks our consultants work from, so a finding traces back to a known attack class and a severity you can verify yourself.
Cross-account testing scanners cannot do
Most serious API breaches are authorization failures, not injection. Finding them requires understanding who should be allowed to do what, something a pattern-matching scanner has no concept of.
You give Operator one bearer token per user type. With two or more, it sends one role’s requests as another and watches what comes back: another tenant’s records, an admin-only function, a resource that should have returned 403. That is BOLA and BFLA, proven with the exact cross-account request and response.
- One token per role, analyst, admin, tenant A, tenant B.
- Requests replayed cross-account to expose broken object and function authorization.
- Read-only by default, only GET, HEAD, and OPTIONS, safe against production.
- Scope-locked to the domain you verified and base URL; excluded operations are never touched.
What a confirmed API finding looks like
Every finding is grouped by severity and ships with the request that triggered it, the response that confirms it, and a CVSS v3.1 vector.
Unauthenticated endpoint leaks admin credentials
An endpoint reachable without a session returns management-panel admin credentials in its response, a full compromise path, confirmed with the exact unauthenticated request.
Splash endpoint issues valid JWT for any device
An unauthenticated operation mints a valid JWT for an arbitrary device_id with no attestation, enabling unlimited account creation. Reproduced and rated.
What a proven API finding looks like, end to end
A confirmed finding is not a paragraph describing a risk, it is the request that triggers it, the response that confirms it, and a command you can run yourself to see it again. Here is one BOLA finding and one BFLA finding in the exact shape every finding in your report takes. See how findings are proven before they ever reach you.
- Authenticated as a standard user and called
GET /api/v1/orders/50713, the user’s own order, a correct 200 OK. - Replayed the identical request with the same token, incrementing the order ID to an adjacent value belonging to a different account.
- The endpoint returned
200 OKwith the other account’s order, shipping address and masked payment details included. - Repeated the swap against two more IDs to confirm the missing check, not a one-off fluke.
GET /api/v1/orders/50714 HTTP/1.1
Host: api.example.com
Authorization: Bearer <STANDARD_USER_TOKEN>
HTTP/1.1 200 OK
Content-Type: application/json
{ "order_id": 50714, "user_id": 9317, "shipping_address": "...", "payment_last4": "4242" }
curl -s https://api.example.com/api/v1/orders/50714 \ -H "Authorization: Bearer <STANDARD_USER_TOKEN>"
Illustrative example, not a specific customer result.
- Authenticated as a standard user and confirmed the role carries no admin scope in its token claims or in the product UI.
- Called the administrative endpoint directly with the standard user’s token, an operation the spec marks for privileged roles only.
- The endpoint executed the request and returned
200 OKwith every order across every account, no role check enforced server-side. - Repeated the call from a second standard user account and reached the same function, confirming a missing check rather than a one-off fluke.
GET /api/v1/admin/orders HTTP/1.1
Host: api.example.com
Authorization: Bearer <STANDARD_USER_TOKEN>
HTTP/1.1 200 OK
Content-Type: application/json
{ "orders": [{ "order_id": 50713, "user_id": 8842 }, { "order_id": 50714, "user_id": 9317 }, "..."] }
curl -s https://api.example.com/api/v1/admin/orders \ -H "Authorization: Bearer <STANDARD_USER_TOKEN>"
Illustrative example, not a specific customer result.
Continuous breadth, human depth
Agentic API penetration testing gives you continuous, spec-driven coverage across every operation, run as often as your API ships. Our manual API security testing adds a senior tester who goes deep on business-logic abuse and chained flaws unique to your product.
They are complementary, not rivals. Most teams run the agent continuously and bring a human in for depth on the highest-risk flows. Both map to the same standards and deliver the same proof-based findings. See how the category works in our guide to agentic pentesting.
- Agentic, continuous, every operation, run on every change.
- Manual, senior human depth on business logic and chained abuse.
- Same standards, OWASP API Top 10, CVSS v3.1, proof attached.
- Delivered where you work, Jira, GitHub, Slack, or export.
Test on every deploy, not once a year
A one-off API pentest is stale the day after it ships, your next release adds an endpoint it never saw. With recurring scans you choose a cadence that keeps pace with your releases instead of a single calendar event. Testing is priced by coverage and scan frequency, so you can run scans between releases and scale the cadence up or down; running more scans adds coverage and increases the price accordingly. For a single yearly checkpoint, an Annual Assessment is one scheduled test per year.
It also finds the class of bug scanners cannot: object and function level authorization. See how we keep noise near zero in reliability and accuracy, and where the market is heading in our state of agentic pentesting report.
- Recurring scans, wired into CI/CD on the cadence you choose.
- Priced by coverage and cadence, scan more often for more coverage; more scans raise the price.
- Every included operation, re-tested, documented operations you include are re-checked as the spec changes.
- Proof, not noise, each finding reproduced before it reaches your tracker.
Common questions about API penetration testing
What is agentic API penetration testing?
Agentic API penetration testing uses an autonomous AI agent to test an API the way an attacker would. It parses your OpenAPI or Swagger spec, enumerates every documented operation, reasons about which are abusable, and tests them for authorization, authentication, and injection flaws across multiple user roles. It reproduces each finding with the exact request and response before reporting it, so you receive proven, exploitable issues rather than a list of unverified alerts.
How is it different from a DAST tool or API scanner?
A scanner matches known patterns on individual requests and cannot understand your business logic. An agent reasons across operations: it sends one role’s requests as another to find broken object and function level authorization, chains a leaked token into a privileged call, and confirms impact by carrying the attack through to effect. Scanners flag; the agent proves.
What does it test?
The OWASP API Security Top 10: broken object level authorization (BOLA), broken authentication, broken object property level authorization and mass assignment, unrestricted resource consumption, broken function level authorization (BFLA), unrestricted access to sensitive business flows, server-side request forgery, security misconfiguration, improper inventory management, and unsafe consumption of APIs, plus classic injection on every parameter the spec exposes.
Do you test authorization flaws like BOLA and BFLA?
Yes, and they are the core of the engagement. You provide one bearer token per user type; with two or more roles the agent sends one role’s requests as another to detect broken object level authorization (BOLA) and broken function level authorization (BFLA), the cross-account and privilege boundary failures that scanners cannot find because they have no concept of who should be allowed to do what.
Is it safe to run against a production API?
Yes. The scan defaults to read-only, sending only GET, HEAD, and OPTIONS, which is safe against production. You can opt in to writes (POST, PUT, PATCH) or to writes plus DELETE for disposable test data. Scope is locked to the domain you verified and the base URL you set, every request stays under that base, and you can exclude any operation before launch.
What do you need to start an API scan?
A domain you have verified, an API base URL under it, and your OpenAPI or Swagger spec (uploaded, linked, or pasted). Optionally, one bearer token per user role to unlock authenticated and cross-account testing, and any global headers such as an API key. The agent parses the spec, lists the operations in scope, and only tests what you include.
How is this different from your manual API security testing?
They are complementary. Agentic API penetration testing gives you continuous, spec-driven breadth across every operation, run as often as your API changes. Manual API security testing adds a senior human tester who goes deep on business-logic abuse and chained flaws unique to your product. Most teams run the agent continuously and bring a human in for depth on the highest-risk flows.
Will it flood us with false positives?
No. Every finding is reproduced before it is reported, with the exact request and response that prove it, so what reaches your tracker is confirmed and exploitable rather than a queue of maybes. Anything the agent cannot reproduce is discarded, and you can route any finding through a senior practitioner for a human signature before it lands.
What is agentic API penetration testing?
Agentic API penetration testing uses an autonomous AI agent to test an API the way an attacker would. From your OpenAPI or Swagger spec, the agent enumerates every documented operation, reasons about which are abusable, and tests them for authorization, authentication, and injection flaws, across multiple user roles at once. Every finding is reproduced with the exact request and response before it reaches your report, so you get proven, exploitable issues instead of a queue of unverified alerts.
Every operation, tested
The agent parses your spec, lists each operation in scope, and tests the ones you include. Only documented operations, no blind fuzzing of endpoints that do not exist.
Authorization, the hard part
Give it one token per role and it sends one role’s requests as another, the BOLA and BFLA failures a scanner can never reason about.
Reproduced, not guessed
Each finding carries a working request and response and a CVSS v3.1 vector. Anything the agent cannot reproduce never reaches you.
Go deeper on API vulnerabilities
BOLA testing
How broken object level authorization is exploited and how Operator proves cross-account access.
Read more → API5:2023BFLA testing
How broken function level authorization lets a normal user reach privileged functions, and how we test it.
Read more → ReferenceOWASP API Security Top 10
All ten 2023 categories explained, with how Operator tests each one.
Read more → MethodologyHow to pentest an API
A practical, step-by-step API penetration testing methodology, from spec to proof.
Read more → GuideBOLA vs BFLA
The difference between the two API authorization flaws scanners miss, side by side.
Read more → ChecklistAPI security best practices checklist
The controls that actually stop API breaches, as a checklist you can work through.
Read more →Test every operation your API exposes
Give Operator your spec and a token per role. It will tell you what an attacker can reach, and prove it.