Key takeaways
- Define scope along four axes: which APIs, which environments, which authentication states and which operation types.
- Hand over your OpenAPI specification or Postman collection before testing starts; without it, endpoint coverage depends on traffic capture alone.
- A methodology statement that lists tools without mapping them to OWASP API Security Top 10 checks is not a methodology statement.
- Each finding must carry the HTTP request, the response that proves exploitation and the reproduction steps for the developer who must fix it.
- Retesting is a separate exercise; a comment that a developer marked an issue fixed is not a confirmed retest.
What an API pentest covers, and what it does not
An API pentest tests your application programming interfaces directly. The tester does not crawl a web application for clickable endpoints. They call your API with and without authentication, mapping authorization logic, testing for injection flaws and finding business logic failures that only appear when requests are built by hand rather than assembled by a browser.
The scope covers the checks in the OWASP API Security Top 10: broken object-level authorization, broken authentication, excessive data exposure, lack of resource and rate limiting, broken function-level authorization, mass assignment, security misconfiguration, injection, improper inventory management and insufficient logging and monitoring. These are not web application vulnerabilities renamed. Object-level authorization failures are the leading API weakness because API callers can enumerate and substitute object identifiers directly in the path, something a rendered HTML page does not easily expose.
A web application pentest and an API pentest overlap when the web application is backed by an API, but they are not the same exercise. A web app tester works with forms, sessions, cookies and the DOM. An API tester works with tokens, paths, verbs and request bodies. If your application has a frontend calling a REST or GraphQL backend, both layers require separate testing. The web application pentest and the API layer are separate targets with separate threat models, and running only one of the two leaves a gap.
Prepare
Scope agreed
APIs, environments, roles and operation types defined
Handover received
Spec, credentials, known issues and out-of-scope list
Test
Inventory built
Spec import and traffic capture fill the endpoint list
Authorization tested
Role by role, object by object across each access level
Injection and logic
Payloads, rate limits, excessive data exposure
Deliver
Report issued
Finding, evidence and reproducible steps per issue
Retest completed
Same requests, confirmed rejection responses
Defining scope before you send the brief
A scope document that says 'our API' is not workable. A tester without a clear boundary will test everything they can reach, which is expensive when the target includes staging systems, internal microservices and partner integrations that were never part of the conversation.
Define scope along four axes. First, which interfaces: REST, GraphQL, gRPC, internal and external facing. Second, which environments: staging is preferred for destructive testing, and production testing requires explicit written authorization with particular care around rate limit checks that could affect live users. Third, which authentication states: unauthenticated surface, standard user, privileged user and administrator, each tested separately. Fourth, which operation types: read-only, read-write or both, and whether destructive operations such as deletion are in scope.
Building an endpoint inventory from specification and live traffic is covered in the article how an API pentest builds its endpoint inventory: specification gaps are filled from observed traffic, and an API version that was never formally decommissioned is the one that most often carries critical findings. Deciding before the test whether deprecated endpoints are in scope or accepted risk keeps the boundary clear and the report clean.
Write the scope as a table of base paths and authentication contexts, not as a paragraph. A tester who must interpret scope from prose will interpret it differently to the buyer who wrote it, and that gap produces disputes about whether a finding was in scope and whose responsibility it is to remediate.
What to hand over before the test starts
An API pentest runs faster and covers more ground when the tester begins with a machine-readable specification. The OpenAPI (Swagger) document, Postman collection or API Blueprint you hand over is imported directly into the testing client. That import surfaces endpoints that passive traffic capture would miss: endpoints called only by background jobs or by internal consumers never appear in browser traffic.
Credentials for each role under test are as important as the specification. A tester who receives no credentials will test only the unauthenticated surface. That surface matters, but the authorization logic behind authentication is where the most common and most severe API findings occur. The article on tokens, rate limits and the controls an API pentest has to evidence explains what authenticated testing covers and why the credential set needs to include each distinct privilege level.
Along with the specification and credentials, prepare a known-issues list covering accepted-risk findings from previous assessments so the tester does not spend time documenting what you already know. Also prepare the out-of-scope list: partner integrations, third-party payment endpoints and anything the tester will reach but cannot test without a separate written authorization from the third party.
| Item | What it enables | Risk if omitted |
|---|---|---|
| OpenAPI or Swagger specification | Full endpoint inventory from day one, including background and internal endpoints | Tester relies on traffic capture; endpoints called only by internal consumers may never be observed |
| Postman or Bruno collection | Pre-built authenticated request sequences ready for the testing client | Manual reconstruction adds time and may miss complex multi-step flows |
| Credentials per role | Authorization testing across standard user, privileged user and administrator access | Only the unauthenticated surface is covered; authorization logic goes untested |
| Known issues list | Tester skips accepted-risk findings and focuses time on new surface | Previously documented issues reappear in the report |
| Out-of-scope list | Partner and third-party endpoints excluded from active testing | Tester may probe endpoints that require a separate authorization to test |
What a credible proposal must say
A proposal that lists tools and states the work will follow industry best practice is not a methodology statement. Ask for the specific checks the tester will run, mapped to a named standard: the OWASP API Security Top 10, the OWASP Web Security Testing Guide API testing chapters, or the technical assessment framework in NIST SP 800-115, which defines what a methodology statement for a security assessment should contain.
Three questions a methodology section must answer. How is the endpoint inventory built: from spec alone, from traffic alone, from both, and what happens when the spec is incomplete or absent? How is authorization tested across roles: how many accounts are needed, how does the tester prove an object belongs to account A and is accessible from account B, and does the scope cover horizontal escalation, vertical escalation or both? What counts as evidence for a finding: an HTTP request and the response that proves exploitation, and manually reproduced steps, not tool output alone.
The article gateway, identity provider or service: where an API pentest should be seen covers the placement question that many proposals leave unresolved. Whether the test runs at the API gateway, at the identity provider or directly at the service affects what gets tested. A proposal that does not address this is likely running all checks at the gateway while the service itself goes untouched.
Confirm delivery terms before signing: who receives the report, whether a debrief call is included and whether retesting is in the original scope or priced separately. Retest pricing omitted from the proposal becomes a negotiation after the findings land, which is the wrong time to have it.
Methodology statement
OWASP API Security Top 10 and WSTG checks mapped explicitly
Endpoint inventory method
How specification gaps and undocumented endpoints are handled
Authorization test design
Roles required, horizontal and vertical escalation both covered
Evidence standard
HTTP request and response, reproducible steps per finding
Delivery and retest scope
Report format, debrief, retesting terms and pricing
How to evaluate the report
The report is the product of the engagement. An API pentest report that lists findings without evidence is a tool output formatted as a document. For each finding, ask whether a developer can reproduce the issue from the report alone. The finding must carry the HTTP request that triggered the vulnerability, the response that demonstrates the impact and the steps required to reach the vulnerable state from an unauthenticated starting point. Object-level authorization findings need the request from account A, the identifier belonging to account A and the request from account B using that same identifier. Without both requests, the developer cannot confirm whether the fix closed the specific path the tester used.
A retest is a separate exercise, not a checkbox. The tester should return the same targeted requests that produced the original findings and confirm they now produce the expected rejection response. A developer's confirmation that an issue is closed is not a retest. The article what an API pentest report must contain covers the full report structure, including how the evidence section is built and what a retest record must show.
Look at how findings are classified. Severity should follow a consistent scale, with CVSS scores or an equivalent framework, and the classification should reflect the actual business impact in your environment, not just the technical severity of the class of vulnerability. A broken object-level authorization finding against a low-sensitivity endpoint scores differently to the same finding against one that returns financial records or personal health information.
Before commissioning an assessment, ask for a sample report. A sample report reveals methodology faster than a sales call: how findings are evidenced, how recommendations are written and whether the report is written for the developer who must fix it or only for the manager who must sign it off.
API security testing in the UAE: what buyers need to know
In the UAE, the strongest demand for API security testing comes from regulated financial services. Firms supervised by the CBUAE, particularly those building open banking or open finance capabilities, expose APIs to third-party developers and partner institutions. Those interfaces carry customer financial data, and the CBUAE's technology risk management guidance requires regular security assessment of systems that process or transmit such data. An assessment covering the OWASP API Security Top 10 categories is a recognised method for evidencing control over those interfaces. Banks and exchange houses operating in both Abu Dhabi and Dubai run this type of assessment as part of their annual technology risk programme.
DESC requirements for Dubai government entities and their ICT suppliers extend to APIs connecting internal systems to public-facing digital services. Abu Dhabi's healthcare sector falls under ADHICS, administered by the Department of Health: clinical APIs connecting hospital information systems, laboratory services and patient portals are sensitive targets that require both testing and evidence of authorization control. At the federal level, the UAE Information Assurance Regulation under TDRA applies to federal entities operating public-facing APIs. For what each regime expects from a formal assessment, the article what UAE regulators expect from an API pentest covers the evidence requirements in full. Organisations in a free zone, whether in Dubai or Abu Dhabi, should confirm the applicable regime with legal counsel before drafting the scope. A penetration testing engagement brief should name the applicable regulatory context explicitly in the statement of work.
Frequently asked questions
What is an API pentest?
An API pentest is a security assessment that tests your application programming interfaces for vulnerabilities including broken authorization, authentication weaknesses, injection flaws and business logic failures. The tester calls your API directly, with and without authentication, using the same techniques an attacker would use. The aim is to find exploitable paths and document them before an attacker does.
How does an API pentest differ from a web application pentest?
A web application pentest assesses the browser-facing layer: forms, sessions, cookies and DOM interactions. An API pentest assesses the interface layer directly: HTTP paths, verbs, request bodies, tokens and authorization logic. If your application has a frontend backed by an API, both layers require separate testing. Vulnerabilities at the API layer, such as broken object-level authorization, do not reliably surface from testing the frontend alone.
Which APIs should be included in the scope?
Include all interfaces that accept external input or carry sensitive data, including internal microservices that communicate across trust boundaries. External-facing REST and GraphQL APIs are the standard starting point. Internal APIs are frequently overlooked and are often less hardened. Deprecated API versions that remain live are a common source of critical findings and should be included unless formally decommissioned and unreachable.
What documentation should I hand over before an API pentest starts?
Provide an OpenAPI or Swagger specification, or a Postman collection if the specification does not exist. Add credentials for each role under test: at minimum a standard user account and a privileged account. Include a list of known issues accepted as risk so the tester does not re-document what you already know, and an out-of-scope list covering partner and third-party endpoints the tester will reach but cannot test without a separate authorization.
What is the OWASP API Security Top 10?
The OWASP API Security Top 10 is a list of the most critical API security risks, maintained by the Open Web Application Security Project. It covers broken object-level authorization, broken authentication, excessive data exposure, rate limiting failures, broken function-level authorization, mass assignment, security misconfiguration, injection, improper inventory management and insufficient logging. A credible API pentest methodology maps its checks to these categories explicitly.
Can an API pentest be run against a production environment?
Production testing is possible but requires explicit written authorization and additional care around rate limit and resource exhaustion checks, which can affect live users. Staging is preferred for the main testing phase. Where production testing is necessary, for example when the staging environment does not reflect live authorization logic, the scope should distinguish which checks run where and what safeguards apply to potentially disruptive tests.
How is authorization tested across different user roles?
The tester needs credentials for each role under assessment: typically standard user, privileged user and administrator. Horizontal privilege escalation is tested by taking an object identifier belonging to one standard user account and attempting to access or modify it via a second standard user account. Vertical escalation is tested by using a standard user account to reach endpoints or operations that should be restricted to a privileged account or administrator.
What evidence should each finding in an API pentest report carry?
Each finding should carry the HTTP request that triggered the vulnerability, the response that demonstrates the impact and the reproduction steps a developer can follow from an unauthenticated starting point. Object-level authorization findings need the request from one account and the request from a second account using the first account's identifier, with both responses shown. Tool output alone, without a manually reproduced request, is not adequate evidence of an exploitable finding.
What is a retest and when should it be included in scope?
A retest is a focused exercise in which the tester returns the same targeted requests that produced original findings and confirms they now produce the expected rejection response. It is separate from the original assessment and should be priced and scoped from the start. A retest confirms that the specific exploitable path has been closed, which is different from a developer's statement that the issue is resolved.
How long does an API pentest take?
Duration depends on the number of endpoints, authentication states and operation types in scope. A focused assessment of a single external-facing REST API with two roles may take three to five days. A broader engagement covering multiple APIs, internal microservices and several privilege levels takes longer. A well-scoped engagement with complete documentation handed over before testing starts will cover more ground in the same time than one where the tester must build the endpoint inventory from scratch.
