API Penetration Testing

We work through the OWASP API Security Top 10 by hand, and broken object-level authorisation usually takes the largest share of the effort. The reason is arithmetic rather than fashion: BOLA is not one test, it is one test per object type, per role, per tenant, so an API with a dozen resource types and three roles generates a great many request pairs that only a person can judge. We swap identifiers between accounts, replay a low-privilege token against a high-privilege object, and read what comes back. Alongside it we test broken authentication, broken function-level authorisation, mass assignment, unrestricted resource consumption and the input-handling categories. Some entries will not apply to your API, and we say which ones and why rather than padding the report to look thorough. Our guide on API security testing services goes through the categories in more depth if you want the longer version before we speak.

We need three things: a definition of the API, environments we are cleared to hit, and accounts. The definition can be an OpenAPI or GraphQL schema, a Postman collection, or captured client traffic, in roughly that order of usefulness. Out-of-date documentation is normal and not a blocker. We reconcile it against real traffic during reconnaissance, and the endpoint and object map we hand back is often the first accurate inventory a team has had in a while. Accounts matter more than people expect. We ask for at least two per role and two separate tenants, because authorisation testing is comparative: without a second identity there is nothing to cross. Staging is fine and often preferable, provided it carries representative data and the same authorisation code as production. If it does not, say so on the scoping call, which runs thirty to forty-five minutes, and we will scope around it.

We test it by holding two tenants at once and trying to cross between them, and the proof is a reproducible request. Working from accounts you provision in separate tenants, we collect object identifiers from the first, then replay them with the second tenant's token across read, write and delete paths, including the endpoints teams tend to forget: exports, webhooks, search, bulk operations, and anything that takes an identifier in a request body rather than in the path. We also check whether tenant context is derived from the token or from a client-supplied field, because the second pattern is where isolation quietly fails. What lands in the report is the request, the response and the record it exposed, so your engineers can reproduce the issue before they debate it. Findings we rate critical are reported within three hours of discovery rather than held back for the report, and a retest is included in the engagement.

Yes, and we agree the limits in writing before we touch anything. Rate limiting sits in the OWASP API Security Top 10 in its own right, so we test whether limits exist, whether they are enforced per account or only per source address, and whether they can be evaded by rotating tokens, altering casing, or moving the same operation into a batch or a nested GraphQL query that costs your database far more than one request should. Abuse cases go beyond volume: credential-stuffing surfaces, one-time-password endpoints, coupon and referral logic, and anything that sends an email or an SMS on an unauthenticated call. Request rates and testing windows are fixed in the rules of engagement. Where a test would genuinely be destructive, we demonstrate it at small scale and describe the rest rather than running it, and keeping production entirely out of bounds is a scoping decision we are happy to make with you.

Test the API separately if it is reachable by anything other than your own front end. A web or mobile test exercises the API through the client, which means it exercises the requests the client knows how to make. The flaws that matter at the API layer are usually in the requests a client would never send: a parameter the app never sets, an endpoint retired from the interface but still routed, an identifier swapped for one belonging to another account. Partner and machine-to-machine integrations have no front end at all. Running both together is the common answer, and they feed each other, since the web or mobile work surfaces traffic and token handling that sharpens the API scope. If budget forces a choice, we would rather scope one thorough API test than thin coverage across two, and the scoping call is where we work that out with you.