API Penetration Testing Explained: Scope Method Deliverables

Most modern applications expose far more surface through their APIs than through their user interface. A single mobile app or single-page frontend can sit on dozens of endpoints handling authentication, payments and administrative actions. API penetration testing exists because automated scanners cannot understand what an endpoint is supposed to do, who should call it, or how chaining two legitimate requests can quietly break access controls. This guide explains the scope, method and deliverables of a professional API penetration test so you can brief a provider and read a quote with confidence.

What API penetration testing actually covers

API penetration testing covers the structured, manual assessment of application programming interfaces to find vulnerabilities an attacker could exploit. It applies whether your API is a REST service, an internal GraphQL gateway, a SOAP integration or a gRPC backend behind a mobile app.

The work is led by a tester reasoning about how each endpoint behaves, not a tool firing payloads at a URL.

The reference framework is the OWASP API Security Top 10. Its most damaging categories are Broken Object Level Authorisation (BOLA), where one user can read or change another user’s records by altering an identifier, and Broken Function Level Authorisation, where a standard user reaches administrative functions. Testers also assess broken authentication, unrestricted resource consumption, mass assignment, security misconfiguration, and unsafe consumption of upstream APIs. These flaws rarely surface in a vulnerability scan, which is why API testing is commissioned as distinct work rather than folded into a generic web assessment.

Scope is defined by the API itself rather than by a network range. A typical engagement covers one or more documented APIs, the authentication mechanism behind them (OAuth 2.0, JWT or API keys), at least two user roles so authorisation can be tested across privilege boundaries, and sensitive workflows such as payment or data export. Our API penetration testing service page sets out that scope.

The method: how a professional API test is run

A credible API penetration test follows a repeatable methodology aligned to OWASP, the PTES (Penetration Testing Execution Standard) and the guidance that underpins CREST-accredited work. The phases below are what our CREST-certified testers follow on every API engagement.

Scoping and documentation review. Testing begins with your API specification, ideally an OpenAPI or Swagger definition, a Postman collection or GraphQL schema, letting the tester map every documented endpoint, parameter and expected response before touching the target. Where documentation is incomplete, testers enumerate hidden and deprecated endpoints, because undocumented routes are a frequent source of serious findings.

Authentication and session analysis. The tester examines how tokens are issued, validated and revoked, including JWT signature verification, token expiry and replay, refresh-token handling, and whether the API leaks information through error messages. Many real-world findings sit here: tokens that never expire, unchecked signatures, or weak secrets that can be brute-forced offline.

Authorisation testing. This is the heart of API testing. Using two or more accounts, the tester attempts horizontal escalation (reading another user’s data by changing an object identifier) and vertical escalation (reaching admin functions from a standard role). Because BOLA and broken function-level authorisation dominate the OWASP API list, a test that skips multiple roles is incomplete.

Input, business logic and data exposure. Testers probe for injection (SQL, NoSQL, command and server-side template injection), mass assignment where extra fields can be smuggled into a request, excessive data exposure where the API returns more than the client needs, and business-logic flaws such as bypassing rate limits or manipulating prices. Resource-consumption checks confirm whether the API can be abused for denial of service.

Reporting and retest. Every confirmed issue is documented with a clear description, a reproducible proof of concept, a CVSS-based severity and specific remediation guidance. Once your team has fixed the findings, a retest validates the work at no extra cost so you can evidence closure.

REST, GraphQL and SOAP: what changes by API type

The methodology is consistent, but the technical detail shifts with the technology, so scope each API type explicitly to avoid a generic test that misses risks specific to your stack.

REST APIs map cleanly to HTTP verbs and resource paths. The dominant risks are authorisation flaws on object identifiers, verb tampering (using PUT or DELETE where only GET was anticipated), and inconsistent enforcement across similar endpoints. Pagination, filtering and search parameters are frequent vectors for data exposure.

GraphQL APIs concentrate logic behind a single endpoint, which changes the threat model. Testers focus on introspection that reveals the entire schema, deeply nested or recursive queries that exhaust server resources, batching attacks that defeat rate limits, and field-level authorisation gaps where a resolver returns data the caller should not see. A test that only checks the HTTP layer will miss most of what matters here.

SOAP and XML-based APIs, still widespread in finance, government and legacy enterprise systems, bring XML-specific risks such as XML External Entity (XXE) injection, SOAP action spoofing and WSDL information disclosure, with WS-Security configurations and signature handling needing dedicated attention.

Deliverables: what you receive from an API test

The output should let a developer fix issues and let a non-technical stakeholder understand the risk. A complete set includes an executive summary for boards and clients, technical findings with severity ratings, reproducible proof-of-concept steps for each issue, and prioritised remediation advice mapped to the OWASP API Security Top 10.

You should also expect a methodology statement recording the standards and scope, an attestation letter for customers, auditors and procurement teams, and a retest report once fixes are verified. For organisations pursuing ISO 27001 or responding to a supplier security questionnaire, this evidence trail is often the real reason the test was commissioned, and a scan report cannot serve that purpose because it shows no human verification or exploitation evidence.

How much an API penetration test costs in the UK

API penetration testing in the UK is priced by tester days at a standard day rate of £1,100 to £1,400, not by a per-endpoint menu. A small, well-documented REST API with a single user role can often be assessed in a few days, while a large GraphQL gateway with multiple roles takes longer.

Effort is driven by scope complexity: the number of endpoints, the number of user roles, the authentication mechanism and the presence of complex business logic.

All testing is delivered by senior and principal testers at a typical UK day rate of around £1,200 to £1,300. A focused API test of four to six days therefore lands in the region of £4,800 to £7,200, with larger or multi-API engagements scoped individually. Avoid providers advertising fixed low prices per endpoint, which usually signals an automated scan. For a fuller breakdown, see our guide to penetration testing cost in the UK.

How EJN Labs approaches API penetration testing

EJN Labs is a CREST-accredited UK penetration testing firm, and every API engagement is delivered by senior and principal testers, never junior or associate staff. Our work is aligned to the OWASP API Security Top 10 and PTES, and as a CREST member company we hold ourselves to the standards that underpin that accreditation. We are also certified to Cyber Essentials, Cyber Essentials Plus, ISO 27001 and ISO 9001, so the evidence we produce stands up to auditor scrutiny.

We price by scope complexity with a fixed quote agreed before work begins, and each test ends with a developer-ready report and a free retest, giving you documented closure rather than a list of open issues. You can see how API testing sits within our wider portfolio on our services overview, or request a scoped quote through our CREST pen testing quote form.

Frequently Asked Questions

How is API penetration testing different from web application testing?

API penetration testing targets the underlying endpoints directly, while web application testing focuses on the browser-facing interface, forms, sessions and client-side behaviour. APIs expose authorisation and business-logic flaws that never appear in the user interface, which is why the two assessments examine genuinely different attack surfaces.

The two assessments are complementary and should be scoped and priced as distinct pieces of work.

Can a vulnerability scanner replace an API penetration test?

No. Automated scanners cannot understand what an endpoint is meant to do or who should be allowed to call it, so they miss Broken Object Level Authorisation, business-logic abuse and most of the OWASP API Security Top 10. Only a manual test finds these classes of flaw.

A scan remains a useful supporting tool. It is the manual test by an experienced tester that provides the exploitation evidence and assurance auditors and customers expect.

What do you need from us before testing can start?

We need an up-to-date API specification (OpenAPI, Swagger, a Postman collection or GraphQL schema), test credentials for at least two user roles, a staging environment where possible, and a named technical contact. With those four items ready, testing can begin promptly.

The more complete the documentation, the more time the tester spends finding real issues rather than mapping the attack surface.

How long does an API penetration test take?

Four to six testing days is typical for a focused test of a single well-documented API, with the report delivered shortly after. Larger estates with multiple APIs, several user roles or complex GraphQL schemas take longer, so duration scales with the size and complexity of the scope.

We confirm the exact duration at scoping, so you have a fixed timeline and price before the engagement begins.

Do you retest after we fix the findings?

Yes. A retest is included at no additional cost. Once your developers have addressed the reported issues, our testers verify the fixes and issue an updated report confirming closure, which you can share with auditors, customers or your ISO 27001 assessor as evidence that the risks have been resolved.

Get a scoped API penetration testing quote

If you are ready to assess your REST, GraphQL or SOAP APIs against the OWASP API Security Top 10, our CREST-certified testers can scope the work and provide a fixed price. Request a tailored quote through our CREST pen testing quote form, or explore our API penetration testing service first. Every engagement includes a developer-ready report and a free retest.