How to run a penetration test on a REST API

You run a useful REST API penetration test in three moves: scope the live surface first, test it with authenticated requests from at least two identities, then repeat the same checks after the fixes land. Skip any of the three and you get either a blind scan, a login test that proves nothing about access control, or a report that nobody can show was closed.

Once an API carries production traffic, you are testing business logic, access control and change drift, not just a list of endpoints. That is what this guide is built around.

Key takeaways

• A REST API pentest starts from scope, an OpenAPI file and authenticated access, not from blind crawling.
• Two distinct user identities are required to catch BOLA / IDOR and role-based authorization flaws.
• The highest-value tests hit authentication, authorization, schema abuse, rate limits and business flows before generic fuzzing.
• Automate spec-based checks in CI/CD, and keep human judgment for authorization edge cases and workflow abuse.

Start with scope, access and two test identities

What to collect before testing

Define the target, the environment and who can approve the work. Pure black-box API testing misses too much: at minimum you need authenticated access, so you can see what a real user can reach.

1. Confirm written authorization, the in-scope base URL and any excluded routes before a request leaves your machine.
2. Ask for the current OpenAPI definition. It is usually the fastest route to the actual attack surface.
3. Prepare two test identities with different roles, plus any admin or service account that is explicitly allowed.
4. Record rate-limit expectations, logging contacts and safe hours for burst testing, so you do not create avoidable noise.

OWASP's DevSecOps guideline on API security calls authorization testing (BOLA / IDOR) the number one API risk, and says it needs explicit test cases because scanners cannot derive valid object IDs. Its recommended method starts exactly here: two test accounts, user A and user B.

Why one token is not enough

A single bearer token tells you almost nothing about authorization boundaries. To expose broken object-level authorization, request a resource as user A, then replay the same object reference as user B and confirm the API denies it. To expose broken function-level authorization, call the same administrative route from a lower-privileged role and confirm the server enforces the role on the backend, not only in the UI. That is the difference between a login test and an authorization test.

Map the attack surface from the spec and from real traffic

Use the OpenAPI file as the fastest route

The OWASP REST Assessment Cheat Sheet puts it plainly: "Modern REST APIs commonly publish a machine-readable description in OpenAPI (formerly Swagger). [...] for an assessment it is the fastest route to the attack surface." Feed the spec into your test plan first, then enumerate:

• Paths and verbs: every endpoint and method, including admin routes and versioned paths.
• Parameters and headers: query, body, path and header inputs that can affect logic or access control.
• Auth schemes: OAuth 2.0, OpenID Connect, JWT and any custom session mechanism.
• Pagination and filters: page size, cursors, deep paging and expensive search parameters.
• Uploads and parsers: file upload routes, content types and parser-sensitive inputs.

Find what the spec misses

Spec drift is normal, so do not trust the file alone. Compare it with proxy captures, changelogs and traffic from a real session: undocumented endpoints and stale schemas are common in live services. If the spec says one thing and traffic shows another, test both. A release branch can also expose admin routes that never made it into the published schema.

Test authentication and authorization first

Authentication checks

Authentication flaws produce serious findings quickly, so test them before anything else. Check missing authentication on sensitive routes, weak session handling, malformed and expired tokens, revoked sessions, JWT tampering, and whether the API accepts a token with the wrong issuer, audience, scope or role. With OAuth 2.0 and OpenID Connect, validate refresh behaviour and revocation, not just login success.

1. Send requests with no token, a malformed token, an expired token and a token from the wrong issuer or audience.
2. Replay a revoked or logged-out session and confirm the server rejects it.
3. Alter JWT claims, where the test environment and authorization allow it, and verify the backend refuses the tampered token.

If the API accepts a structurally valid JWT that should no longer work, that is a real flaw.

Authorization checks across users and roles

Broken object-level and function-level authorization both need explicit tests. Use user A to request /accounts/123, then replay the same reference as user B and confirm access is denied. Repeat the pattern on nested properties, administrative functions and cross-tenant data.

Test direct object references, list endpoints, update endpoints and any route that reveals whether a record exists. A clean denial on read does not guarantee a clean denial on update. This is where many teams stop too early: the login works, the token is valid, and user B can still change user A's data through the one method the backend forgot to protect.

The same logic applies to GraphQL, with resolvers in place of routes. We cover that variant in our GraphQL security testing guide.

Probe validation, resource limits and business flows

Schema and input abuse

Test the API against its schema with positive, negative and boundary cases. Positive tests confirm valid inputs work. Negative tests confirm invalid types, missing fields and wrong formats fail. Boundary tests check length, depth, count and numeric limits.

• Mass assignment: send extra JSON fields such as role or is_admin and check whether the server overwrites protected attributes.
• Parameter pollution: repeat the same parameter in several places and inspect which one wins.
• Method abuse: try PUT, PATCH, DELETE and unexpected OPTIONS behaviour on sensitive routes.
• Parser edges: vary content types, file extensions, encodings and malformed bodies.

Consumption and workflow abuse

Resource exhaustion is a real API risk. Test burst requests, large payloads, deep pagination, expensive filters and concurrent token use. A rate limit that exists on paper but collapses under parallel requests is still a flaw.

Then move to business flows: checkout, payout, password reset, invitation and refund often break in places a generic scanner never understands. That is where you find duplicate redemption, replayed requests and state changes accepted out of order. Repeat sensitive steps out of sequence and confirm the backend blocks them.

The cost of missing these is not abstract. IBM's 2025 Cost of a Data Breach report puts the global average cost of a breach at $4.44 million, based on 600 organisations breached between March 2024 and February 2025.

Automate the repeatable parts in CI/CD

What to automate

Automate discovery, schema-based fuzzing and baseline regression checks. Schemathesis is a good example of schema-driven testing, and ZAP's API scan imports an OpenAPI definition for API-aware DAST instead of crawling blindly. The value is not that one tool finds everything. It is that the pipeline catches regressions as the API changes.

Use fail, warn and pass thresholds. A broken authorization control fails the build, a suspicious but unconfirmed issue warns, a clean run passes. That keeps the output useful to engineering instead of turning every deviation into a hard stop.

Automation area	Typical tool	Best for	Key limit
Schema fuzzing	Schemathesis	Contract and boundary regressions	Does not judge business logic
API DAST	ZAP with OpenAPI import	Baseline exposure and simple auth issues	Needs good auth context and manual validation

What still needs human judgment

BOLA / IDOR verification, role boundaries, chained requests and workflow abuse that depends on timing or state still need someone who understands what the API is supposed to allow. Automated checks cover the obvious regressions. Testing covers the question a scanner cannot answer: does this user see the wrong object, and can they complete the wrong action all the way through?

Report findings so engineers can fix them fast

What a useful finding looks like

A useful API finding is reproducible in one request chain and short enough for an engineer to act on. At minimum: endpoint, method, prerequisite identity, exact request, expected versus actual result, severity, business impact, remediation and retest status. If the issue depends on two identities, say so and attach both request traces.

1. Record the exact route, method, headers, body and the identity used to reproduce the issue.
2. State the expected result and the actual result in one line each.
3. Explain the business impact in plain words: cross-tenant data exposure, unauthorized payout, account takeover risk.

Retest and close the loop

Reduce false positives by reproducing the issue with the real request chain, not a single raw packet, and by confirming authorization with the second identity where relevant. Triage in this order: internet-exposed authorization flaws, authentication bypass, sensitive data exposure, resource exhaustion, then lower-risk validation bugs. When the fix lands, rerun the same request chain and close the finding only after the server rejects the abuse in the same context.

Retesting has to be part of the workflow, not left to memory. Edgescan's 2026 vulnerability statistics report that the average mean time to remediate high and critical application and API vulnerabilities in 2025 was 54.81 days. That is several release cycles with a known hole in production. If the API falls under NIS2, that test, fix and retest chain is also your audit evidence, as covered in our piece on API pentesting for NIS2.

Where Fleuret fits

Fleuret runs agentic pentests on web apps, REST and GraphQL APIs and external infrastructure, with results in hours. Each finding ships with a replayable proof of concept, so the request chain above is already written down. Findings are pushed to Jira, Linear or Slack, mapped to DORA and NIS2, and retested after the fix, with a signed report on demand.

What I recommend

Take the current OpenAPI file, two real user roles and one production-like test environment, then run the workflow in this order: authentication, authorization, schema abuse, resource limits, business flows. If the API changes every sprint, the hard part is not finding one bug. It is keeping the same test motion alive while the attack surface moves, so plan the retest before you start the first test.

Fleuret runs agentic pentests on REST APIs with replayable PoCs, tickets and a retest after every fix. See Fleuret in action.

Sources

• API Security, OWASP DevSecOps Guideline
• REST Assessment Cheat Sheet, OWASP Cheat Sheet Series
• REST Security Cheat Sheet, OWASP Cheat Sheet Series
• IBM Report: 13% of organizations reported breaches of AI models or applications, IBM Newsroom, 2025-07-30
• What the 2026 Vulnerability Statistics Report tells us about the state of security, Edgescan, 2026
• ZAP API Scan, ZAP
• Schemathesis, Schemathesis