Home
Penetration testing
API penetration testing

API penetration testing built around the OWASP API Top 10

APIs break on authorisation and logic, not injection, and the UI hides most of the surface. We test every endpoint directly, as every role.

Get a quote See a sample report

What an API test covers

01 · What we test

Where APIs break: authorisation

APIs fail differently from web apps. The top risks are authorisation and logic, not injection. We test against the OWASP API Security Top 10.

Broken object-level authorisation

The number-one API risk: changing an ID to read or change another user’s data (BOLA)

Authentication & tokens

JWT handling, API keys, OAuth scopes and session flaws

Business logic & mass assignment

Rate limiting, workflow abuse, and setting fields the client shouldn’t control

Excessive data exposure

Endpoints that return more than the UI shows, and verbose error messages

Scope your API test

02 · Why APIs need their own test

The UI hides the attack surface

A web scanner follows links a browser can see. An API has no UI to crawl, so most of its endpoints — and its risk — are invisible to automated tools.

Web scanner

API test

Endpoint discovery

Only what the UI links to

The full surface, from your OpenAPI spec and traffic

Authorisation

Assumes the UI enforces it

Calls every endpoint as every role, directly

Object access (BOLA)

Not tested

Iterates IDs across accounts to prove cross-tenant access

Mass assignment

Not tested

Sets hidden fields like role or is_admin in the request body

Test your API directly

03 · A sample finding

What an API finding looks like

Redacted from a real engagement. Proof, impact and a fix.

Two-layer reportBoard summary plus endpoint-by-endpoint technical proof, mapped to the OWASP API Top 10.
Developer walkthroughA session with your engineers to get the authorisation model right.
Free retestWe re-test the fixes and attest to closure, included.

Want the full sample report? Ask for it in the form and we’ll send it.

API-01Sample finding · redacted

Broken object-level authorisation (BOLA) on the orders endpoint

SeverityCritical

CVSS8.1

StandardOWASP API1

Evidence

GET /api/orders/7781 as user A → 200 (own)
GET /api/orders/ as user A → 200 (user B’s order)

Business impact

Any authenticated user could read and modify any other customer’s orders by changing the ID — a reportable breach and a fraud risk.

Fix

Enforce an ownership check on every object access server-side, keyed to the authenticated identity, not a client-supplied ID. Add authorisation tests to CI.

Confirmed across two test accounts.Retest: fixed

See what you’d get

Starting from€4,000

Priced on endpoints and roles

An API test starts here and scales with the number of endpoints, user roles and authentication flows in scope. See penetration testing pricing.

Get a fixed quote

05 · Questions

API penetration testing FAQ

Get a quote

How do you scope an API test?

By endpoints, user roles and authentication flows, not pages. An OpenAPI (Swagger) spec or a Postman collection makes scoping precise; if you don’t have one, we build the surface from traffic and documentation.

Do you test REST and GraphQL?

Both, plus gRPC and SOAP where relevant. GraphQL gets extra attention on query depth, batching abuse and field-level authorisation, which are easy to get wrong.

Why can’t a web app scanner cover the API?

Because an API has no UI to crawl. Most endpoints and the biggest risks — broken object-level authorisation, mass assignment — are invisible to a scanner. See the difference on our web application testing page.

Which standard do you follow?

The OWASP API Security Top 10, so your findings map to the framework your developers and auditors already use. Each finding cites the specific API risk it falls under.

Do you need credentials for every role?

Yes, ideally. Authorisation flaws only show up when we can call endpoints as each role and compare. Test accounts for each privilege level make the test far more valuable.