How to pentest an API
A practical, ordered methodology for penetration testing an API, run as a checklist against the ten OWASP API Security Top 10 (2023) categories, from enumerating every operation to reporting with CVSS and remediation. Each category names what to test, one concrete request pattern, and what a proven finding looks like, so you can follow it by hand or understand what Operator does on every run.
Written by Berk Dusunur, Founder & CEO, Planck Proof · Updated September 2026
Scope, authorization, and prep
A pentest begins with written authorization and a rules-of-engagement agreement, never before. Agree on the environments in scope, the roles and tenants you will test as, the rate ceilings, and which destructive actions require explicit sign-off. Testing is read-only by default against production, so a live system is assessed without being degraded. Two prep steps come first, then the methodology runs as a checklist against every category in the 2023 OWASP API Security Top 10. This mirrors our API penetration testing engagement and the full methodology.
Enumerate every operation from the spec
Manual: collect the OpenAPI, GraphQL SDL, or protobuf definitions and list every endpoint, method, and parameter, then hunt undocumented, retired, and debug routes by hand.
Automated: the agent ingests the spec via OpenAPI-driven testing, enumerates every operation, and rebuilds the reachable surface each run, including shadow and zombie endpoints.
Map authentication and get one token per role
Manual: learn the auth model, provision credentials for each role and tenant, and probe token issuance, validation, expiry, and revocation for weaknesses.
Automated: the agent takes one token per role and exercises the token lifecycle as an attack surface while it works. See API authorization testing.
Everything below is the same list, in the same order, as the OWASP API Security Top 10 (2023). Work down it as a checklist: for each category, test the pattern shown, and treat nothing as a finding until it is reproduced with the request and response that prove it. This is the same coverage Operator runs against your REST API or spec on every scan.
API1: Broken Object Level Authorization (BOLA)
What to test: every operation that accepts an object identifier, an order, invoice, record, or user ID, in the path, query string, or body. Build an authorization matrix of role by object type and call each object-scoped operation with more than one identity. This is API1 for a reason: it is the most common root cause behind real, disclosed API breaches, and sequential or predictable IDs make it the cheapest one for an attacker to find.
GET /api/v1/orders/{id} HTTP/1.1
Authorization: Bearer <ACCOUNT_A_TOKEN>
# repeat with an id that belongs to a different account, same token
What a proven finding looks like: the response returns 200 OK with another account’s object instead of a 403 or 404, reproduced against more than one identifier so it is a missing check, not a fluke. See BOLA testing.
API2: Broken Authentication
What to test: token issuance, expiry, and revocation, password reset, and any endpoint that should require a session but might not. Try a missing Authorization header, a tampered signature, and an expired or already-revoked token. Also check for hardcoded API keys, JWTs accepted with the alg claim set to none, and refresh tokens that outlive the session they belong to.
GET /api/v1/account HTTP/1.1 Host: api.example.com # no Authorization header sent
What a proven finding looks like: the request still returns 200 OK with account data instead of 401, whether the header is missing, the token is expired, or the signature is tampered.
API3: Broken Object Property Level Authorization
What to test: individual fields on reads and writes, not just the object as a whole. Look for excessive data exposure on responses and mass assignment on updates, fields the caller can read or set that it should not be able to. Pay attention to nested objects and internal-only fields the client application never renders, since a field the UI hides is not the same as a field the API rejects.
PATCH /api/v1/users/{id} HTTP/1.1
Content-Type: application/json
{"name": "...", "role": "admin"}
What a proven finding looks like: appending an unadvertised field, such as role or is_verified, to a routine update is accepted and changes a value the caller should never control.
API4: Unrestricted Resource Consumption
What to test: pagination limits, batch endpoint size, file upload limits, and expensive operations such as search, export, or report generation that any authenticated caller can invoke with no ceiling. Include operations that fan out into several downstream calls per request, where the visible cost of one request hides the real cost behind it.
GET /api/v1/records?page_size=100000 HTTP/1.1 Authorization: Bearer <STANDARD_USER_TOKEN>
What a proven finding looks like: a single request returns an unbounded result set or triggers disproportionate backend cost, with no size cap or rate limit enforced.
API5: Broken Function Level Authorization (BFLA)
What to test: every operation the spec marks admin, internal, or privileged. Call it directly with a lower-privileged role’s token instead of going through the UI that hides the option. Function-level checks are easy to add to a menu and easy to forget on the route underneath it, so test the endpoint itself, never the interface in front of it.
POST /api/v1/admin/{action} HTTP/1.1
Authorization: Bearer <STANDARD_USER_TOKEN>
What a proven finding looks like: the privileged action executes and returns 200 OK for a caller whose role should never reach it, reproduced from a second lower-privileged account. See BFLA testing.
API6: Unrestricted Access to Sensitive Business Flows
What to test: multi-step flows such as purchase, transfer, referral, and coupon redemption, for logic that authorization checks alone do not catch. Automate the flow at volume rather than exercising it once by hand. Include step-skipping, calling step three of a flow without ever completing step two, and race conditions from firing the same request in parallel.
POST /api/v1/coupons/redeem HTTP/1.1
Content-Type: application/json
{"code": "WELCOME10"}
# repeated at automated scale, same account
What a proven finding looks like: a flow meant to run once per account, a signup bonus or a single redemption, can be driven repeatedly with no server-side limit, at real financial or business cost.
API7: Server-Side Request Forgery (SSRF)
What to test: any parameter that makes the server fetch a URL on the caller’s behalf: webhooks, avatar-by-URL, PDF generation, and import-from-link features. Cloud deployments raise the stakes here, since a successful fetch against an instance metadata endpoint can hand over the credentials the whole service runs on.
POST /api/v1/webhooks HTTP/1.1
Content-Type: application/json
{"callback_url": "http://169.254.169.254/latest/meta-data/"}
What a proven finding looks like: the server fetches the attacker-supplied internal or cloud metadata address and returns or leaks its response to the caller.
API8: Security Misconfiguration
What to test: CORS policy, security headers, verbose error output, unnecessary HTTP methods, and default credentials left enabled on production hosts. One overly permissive setting here can quietly undo every authorization check tested in the categories above it.
OPTIONS /api/v1/orders HTTP/1.1 Origin: https://evil.example
What a proven finding looks like: the response allows an arbitrary origin with credentials via Access-Control-Allow-Origin, or a stack trace in an error body discloses internal paths and library versions.
API9: Improper Inventory Management
What to test: shadow and zombie endpoints, retired API versions still deployed, and staging or debug routes reachable from the internet that the current spec omits. Old versions are rarely retired with the same rigor they were shipped with, so check for them on every engagement, not only the first.
GET /api/v0/users HTTP/1.1 Host: api.example.com # a retired version still live behind the current one
What a proven finding looks like: an old or undocumented version answers requests with weaker or no authorization checks compared to the current one.
API10: Unsafe Consumption of APIs
What to test: how your API trusts data it receives from upstream and third-party APIs before reusing it, without validating or sanitizing the response first. This category increasingly covers AI integrations too: an agent or tool call that returns text or structured data from a third-party model deserves the same skepticism as any other upstream response.
POST /api/v1/integrations/sync HTTP/1.1 # trigger the integration, then inspect what the upstream response # is allowed to do downstream: storage, rendering, another call
What a proven finding looks like: data returned by a third-party API is passed through to storage, rendering, or another internal call unvalidated, letting a compromised or malicious upstream inject into your own system.
Read-only by default
The methodology above can run against a live system without degrading it, provided the safeguards are built in. Read-only operations are the default, request volume is throttled to agreed ceilings, and any write, delete, or expensive operation is gated behind explicit approval rather than treated as a free action.
That discipline is what lets testing be continuous rather than a once-a-year event scheduled around a maintenance window. For where continuous testing fits against annual testing, see Meet Operator and the engagement methodology.
- Read-only default against production, writes gated by approval.
- Throttled volume to ceilings agreed at scoping.
- Authorization first, since BOLA and BFLA cause the most damage.
- Proven findings, each with reproducible evidence.
- Retest to verify fixes once they ship.
API pentesting checklist
The same methodology as one list. Copy it into your tracker and check items off as you go, whether you are testing by hand or reviewing what an agentic run covered.
- Get written authorization and a rules-of-engagement agreement before any request is sent.
- Enumerate every operation from the OpenAPI, GraphQL SDL, or protobuf definition, plus undocumented and retired routes.
- Obtain one token per role and tenant in scope; test issuance, expiry, and revocation.
- API1 BOLA: replay object-scoped requests across accounts using each other’s identifiers.
- API2 Broken Authentication: call sensitive endpoints with a missing, tampered, or expired token.
- API3 Object Property Level Authorization: test mass assignment and excessive data exposure per field.
- API4 Unrestricted Resource Consumption: check pagination, batch size, upload limits, and rate limits.
- API5 BFLA: call every admin or privileged operation with a lower-privileged role’s token.
- API6 Sensitive Business Flows: automate purchase, transfer, referral, or redemption flows at volume.
- API7 SSRF: supply an attacker-controlled URL to any server-side fetch parameter.
- API8 Security Misconfiguration: check CORS, headers, verbose errors, and default credentials.
- API9 Improper Inventory Management: hunt shadow, zombie, and undocumented API versions.
- API10 Unsafe Consumption of APIs: check how upstream and third-party responses are trusted downstream.
- Reproduce every candidate with request and response evidence before it counts as a finding.
- Rate each finding with CVSS v3.1, attach remediation, and retest once fixes ship.
Common questions
What do you need before you can pentest an API?
At a minimum, a definition of the API and credentials to reach it. A specification, whether an OpenAPI document, GraphQL SDL, or protobuf definitions, lets you enumerate every operation instead of guessing, and one token per role and tenant lets you test authorization properly. Written authorization and a rules-of-engagement agreement come first, since testing without permission is not a pentest.
Can you pentest an API safely in production?
Yes, with care. Read-only operations by default, throttled request volume agreed at scoping, and destructive actions gated behind explicit approval let you test a live system without degrading it. Operator defaults to read-only against production and treats writes and expensive operations as controlled steps rather than free actions.
What is the most important part of an API pentest?
Authorization testing across roles and accounts. BOLA and BFLA cause most real API breaches and are exactly what scanners cannot find, because detecting them requires comparing what different identities are permitted to reach. If a methodology skips the authorization matrix, it is missing the highest-severity findings on most APIs.
How is an agentic API pentest different from a scanner?
A scanner runs fixed signatures against endpoints and produces alerts. An agentic tool reasons about the API from its specification, tests every operation across roles, chains steps into a working exploit, and proves each finding with evidence. It automates the manual methodology on this page rather than replacing it with pattern matching.
Run this methodology on your API
Give us a spec and one token per role, and the agent runs every step, from enumeration to proven findings and a CVSS report. Start with BOLA testing and BFLA testing.