02 / Stack layerWEB & API

API penetration testing: who gets which object.

API security testing checks whether your API hands each object only to the caller who may have it. In an API penetration test we call every endpoint as every role and tenant, test authentication, token handling and rate limits, and look for the versions and endpoints nobody documented. Findings map to the OWASP API Security Top 10 (2023), are rated in CVSS v4.0 and come with the exact requests.

For teams whose API is the product, or the real front door behind a web and mobile app.

Package
WEB & API
Range, excl. VAT
EUR 5,000 to 15,000
Testing days
4 to 10

OBJECTS / FICTION / TWO TENANTS, ONE API04 ROWS READ / 1 FOUNDSAMPLE

TENANT ATOKEN OF TENANT A

  1. CLM-48211200 / OWN
  2. CLM-48212200 / OWN

TENANT BSAME TOKEN

  1. CLM-48213200 / NOT OWN
  2. CLM-48214403 / NOT OWN

CLM-48213 / OWNERSHIP NOT CHECKED / API1:2023

Tenant A’s token is refused one of tenant B’s claims and served the other: the endpoint checks the token, not who owns the object. We test every endpoint that takes an id with two tenants and every role.

What does an API finding look like?

One card per finding, with the same fields every time. This one comes from the fictional engagement in our sample report: an insurer’s claims API.

SAMPLE / FICTIONAL CLIENT / REAL FORMAT

SAMPLE-01 / F-01

CRITICALCVSS-B 9.3STACK LAYERAPI1:2023

The claims API serves any tenant’s claim to the assistant’s token

Business impact
Anyone who can steer the assistant can read and change another customer’s claim.
Evidence
REQUESTS REQ-07 TO REQ-11, APPENDIX B The requests that reproduce it, with both test accounts named.
CVSS v4.0 vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Fix principle
Check authorization on every object, not only at login: scope the assistant’s token to one tenant and enforce claim ownership in the API.
Retest
FIXED 2026-09-24 Ownership is now enforced per claim; all five requests are refused.
The format every finding takes in our report. The client and the finding are fiction; the fields are not. Read F-01 in the sample report.

How does an API penetration test run?

We start from your specification and keep going where it stops being true.

  1. 01Inventory

    We compare the documented API with the live one.

    Your OpenAPI description or GraphQL schema is the starting point, captured traffic from your own clients the second, and the difference between the two can be the first finding: old versions, internal endpoints and fields the documentation never mentions.

  2. 02Authorization matrix

    We build a matrix of callers and objects.

    Two tenants, every role, every endpoint that takes an id. Our tooling replays each request as each caller; a person reads the matrix and decides which cells are a breach and which are the design. Broken object level authorization shows up here, if it is there.1

  3. 03Tokens

    We test the whole life of a token.

    Issue, scope, audience, expiry and revocation, plus the flows that hand tokens out. A token that is valid for more than its task is how a small bug becomes access to another customer’s data, so every finding records which token it used.

  4. 04Limits and flows

    We test limits without taking you down.

    Rate and size limits are checked with measured, low-volume requests inside the agreed windows, never with load. Sensitive business flows are tested for automation at the level any of your own customers could reach.

  5. 05Evidence

    Every finding ships with its requests.

    Each finding carries the exact request and response, the caller it was sent as, its OWASP API id and a CVSS v4.0 rating.

What do we test in an API?

The OWASP API Security Top 10 (2023), one row each, plus the GraphQL and API checks from the Web Security Testing Guide. Broken object level authorization heads the list: it is the bug that hands one customer’s record to another.2

Every row is a category in our test catalogue. Ids link to the framework that defines them.
No.CategoryWhat we checkMapped to
01Object level authorization on every endpointWhether every endpoint that takes an object id checks that this caller may have this object.
02API authentication and token handlingHow tokens are issued, validated, scoped and revoked, and whether any endpoint skips the check.
03Property level authorization on reads and writesWhether responses return fields the caller should not see, and whether requests can set fields the caller should not change.
04Rate limits and resource consumption controlsRate limits, page sizes and payload sizes, so one client cannot exhaust the service or your bill.
05Function level authorization for roles and admin routesWhether admin and role-specific functions refuse callers without that role, on every version still running.
06Protection of sensitive business flowsWhether flows such as sign-up, checkout or booking can be automated at a scale that hurts the business.
07Server side request forgery defensesWhether URLs the API fetches on a caller’s behalf can be pointed at internal services or cloud metadata.
08API security configuration and hardeningConfiguration and hardening: CORS, headers, error detail, TLS and HTTP methods nobody uses.
09API inventory, versions and undocumented endpointsWhich versions, hosts and endpoints are live, including the ones missing from the documentation.
10Safe consumption of third-party APIsHow the API treats data from the third-party APIs it calls, and whether it trusts them more than its own users.
11GraphQL and API surface reviewGraphQL schemas and introspection settings, query depth and batching limits, and the authorization behind every resolver.

Out of scope Load and denial-of-service testing: we check that limits exist, not where the service falls over. Third-party APIs you call are out of scope without their owner’s written permission.

What does an API penetration test cost?

API testing is priced as our Web & API package, excluding VAT. One API with a published specification and a few roles sits near the low end; the quote after the scoping call sets the exact figure.

02 / Stack Pentest

WEB & API

EUR 5,000 to 15,000

TYPICALLY 4 TO 10 TESTING DAYS

What moves the price

  • Endpoints and versions in scope
  • Roles and tenants in the authorization matrix
  • REST, GraphQL or both
  • Whether a specification exists, or we build the inventory

See all prices

Report
Scope, method, dates, findings with evidence, severity in CVSS v4.0, framework ids, fix guidance and retest status.
Attestation letter
One page that confirms scope, dates and retest status, for customers who need the result without the findings.
Coverage matrix
Every category in scope marked tested, not applicable or out of scope, so the gaps are written down too.
Evidence
The request and response pair behind every finding, ready to replay.

Questions about API testing.

What is API security testing?

API security testing checks whether an API gives each caller only what that caller may have. A penetration test does it by hand: every endpoint as every role and tenant, authentication and token handling, rate limits, and undocumented endpoints. Findings map to the OWASP API Security Top 10 (2023) and come with the exact requests.

Do you test GraphQL as well as REST?

Yes. GraphQL moves authorization from routes into resolvers, so we test the check behind every field and resolver, along with schema exposure, query depth, batching and the cost limits that stop one query from doing the work of thousands. REST and GraphQL in the same API are one scope.

What is broken object level authorization?

Broken object level authorization means an API returns or changes an object without checking that the caller may access it, so a different identifier reaches someone else’s data. OWASP ranks it API1 in the 2023 API Security Top 10. We test for it with accounts in at least two tenants and every role.

What do you need from us for an API pentest?

A specification if you have one, such as an OpenAPI description or a GraphQL schema, test accounts for every role in at least two tenants, and a test environment with realistic data. Without a specification we build the inventory from your clients’ traffic, which takes part of the testing days.

Do you test rate limits on production?

Only with measured, low-volume requests inside the windows in the rules of engagement, and never as a load test. We confirm that limits exist and apply per client, token and endpoint; we do not look for the point where the service falls over. Capacity testing is a different job.

The engagement, in short.

4 to 10 testing days on staging where we can, under the rules of engagement you sign first. Then the report and a one-page letter, and the retest once you have fixed. Every step, from the scoping call to the regression pack, is in the method.