An API pentest is the browser taken out of the picture. Here is the sequence a real engagement follows, what has to be ready before the first request, how long each shape of API tends to take, and the questions this test does not answer.
An API pentest is an authorised, mostly manual attack against the interfaces your systems expose to other systems: REST endpoints, GraphQL schemas, gRPC services, webhooks, and the backends behind your mobile apps. NIST SP 800-115 describes penetration testing as security testing in which assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system or network.
An API pentest is that with the browser taken out of the picture, and the removal is the point. An API caller sends whatever it likes, in whatever order, with whichever token it holds, so every assumption your front end quietly enforced has to be enforced again on the server.
Verizon’s 2026 Data Breach Investigations Report puts exploitation of vulnerabilities at 31% of breaches with a known initial access vector, up from 20%, making it the most common way in, ahead of credential abuse at 13%.
NIST is explicit that no actual testing occurs in the planning phase: its job is to identify rules, finalise management approval and set testing goals. The rules of engagement outlive the test, and for an API they answer more than which hosts are in scope.
/v1 answers as well as /v3, both are in scope.The OWASP API Security Top 10 lists Improper Inventory Management as API9:2023 and describes the threat as attackers getting unauthorised access through old API versions or endpoints left running unpatched and using weaker security requirements. Its own questions are worth answering whether or not you hire anybody: which environment is this host in, who should reach it, which version does it serve.
NIST splits discovery in two: information gathering and scanning, then vulnerability analysis. For an API the first half is inventory work, and your specification is a starting point rather than the answer.
The endpoint list gets built from several directions at once: the specification, the traffic a real client produces when its flows are driven end to end, the JavaScript bundles and mobile binaries that call the API, and path patterns extrapolated from what is known. Endpoints that answer but appear in no specification are shadow APIs, and they are what API9:2023 is about: forgotten routes running unpatched under weaker security requirements, because nothing that reviews the documented surface ever looked at them.
Alongside it we map the identity model: how a token is issued, what it carries, and whether OAuth 2.0 scopes and JWT claims are checked at the resource server or only at the edge. API2:2023 lists the ways that goes wrong, including APIs that accept unsigned tokens and APIs that never validate the expiry date.
Every kind of pentest has one phase that belongs to it alone. For APIs it is authorisation: the OWASP API Security Top 10 spends three of its ten entries there, on broken authorisation at object level (API1:2023), object property level (API3:2023) and function level (API5:2023).
OWASP’s rule is one sentence: every API endpoint that receives an ID of an object, and performs any action on the object, should implement object level authorisation checks. Broken object level authorisation is what is left when it does not, and OWASP rates it easy to exploit, widespread and easy to detect. It is tested on every parameter that names an object, not a sample.
GET /v2/invoices/8842
Authorization: Bearer <user A, owner of 8842>
200 OK
GET /v2/invoices/8842
Authorization: Bearer <user B, unrelated tenant>
200 OK <- the finding
API3:2023 folded two entries from the 2019 edition, Excessive Data Exposure and Mass Assignment, into one idea: the object is yours, but not all of its properties are. A response returns fields the caller should never see, or mass assignment adds "role": "admin" to a body the server binds straight onto its model.
Broken function level authorisation applies the same failure to operations: an endpoint a normal user should never call, reached by changing the verb, guessing the administrative path, or replaying a request from a privileged session. The productive tests are dull: swap GET for PUT and DELETE, and call every administrative route found in reconnaissance with a low-privilege token.
Injection through parameters that never touch a form, server-side request forgery through URL fields the server fetches for you, and resource consumption. API4:2023 lists limits that ought to exist and rarely all do: execution timeouts, upload size, records per page, third-party spending limits, and operations per request, which for GraphQL means batching and query depth. The OWASP Web Security Testing Guide covers GraphQL as test WSTG-APIT-01.
Last comes the one thing no scanner finds: API6:2023, unrestricted access to sensitive business flows. OWASP’s own example is buying an entire stock of a high-demand item to resell it. Nothing in that request is malformed; the flaw is that the flow allowed itself to be automated.
NIST draws the line precisely: while vulnerability scanners check only for the possible existence of a vulnerability, the attack phase of a penetration test exploits the vulnerability to confirm its existence. Nothing reaches the report as confirmed until it has been reproduced.
The phase loops. NIST’s four-stage diagram draws a feedback path from attack back to discovery, and its text notes that most penetration tests look for combinations of vulnerabilities that grant more access than any single one. Each successful exploit feeds new material back into reconnaissance, which is why an API test produces chains rather than a flat list.
Verification stays conservative. Reading one record belonging to another tenant proves the isolation failure; enumerating the tenant turns a test into an incident. NIST is candid that systems can be damaged during penetration testing and that experienced testers reduce that risk without ever fully eliminating it. That is why the stopping rule is agreed in phase one.
NIST notes that the reporting phase occurs simultaneously with the other three, and that is how it should feel: a critical finding is raised the day it is confirmed, not in a PDF three weeks later. The Penetration Testing Execution Standard organises the same work into seven sections, from pre-engagement interactions and intelligence gathering through threat modelling, vulnerability analysis, exploitation and post exploitation, ending in reporting.
A finding is closed when it has been proved closed. A retest re-runs the reproduction steps for every issue you fixed and, where the fix touched shared code, checks the neighbouring endpoints that used the same pattern. A change applied to one controller while eleven others keep the old shape still reads as fixed, if the only endpoint retested is the one named in the report.
The 2026 DBIR found only 26% of critical vulnerabilities, defined there as those in the CISA Known Exploited Vulnerabilities catalogue, fully remediated by organisations during 2025, down from 38%, with the median time to full resolution rising to 43 days from 32. That catalogue held 1,655 entries in the version published on 27 July 2026.
Shapes, not promises. The useful thing to know before you ask is that the driver is not the endpoint count.
What moves the number is roles multiplied by object types rather than endpoint count, so two extra tenants add more work than twenty extra endpoints; whether a usable specification exists, since rebuilding one by hand can absorb a large part of the engagement; and environment quality, because staging with empty tables hides the findings the test exists to produce.
The working days go in writing once we have seen the surface. Any number quoted before that is a guess with a decimal point on it.
Our API pentesting service follows this sequence. The same walkthrough exists for how a web application pentest works and how a mobile application pentest works, and the shape they all share is in our end-to-end pentesting methodology.
Every figure and framework reference above comes from one of these documents.
The real sequence of an external network penetration test: scope and rules of engagement, reconnaissance, perimeter analysis, exploitation, reporting and retest, plus what the test will not cover.
The sequence of a real internal network penetration test: the starting point we agree, what a domain account becomes, what you get at the end, how long it takes and what the exercise deliberately does not cover.
The real sequence of a wireless penetration test, from the rules of engagement to the retest: what happens at each phase, what you need ready, how long it takes, and what this test deliberately does not cover.
If any of this looks like a problem you are carrying, half an hour on a call scoping it with a senior pentester is worth more than reading another article.
Hablar con un pentester seniorPick a time that suits you. You tell us what you need and where you are, and we explain how we work and how we can help.
