API Pentest (API VAPT)

An API pentest is included in a web application pentest only if it is scoped in. The two overlap but they are not the same surface, and a report that covered one does not evidence the other.

A web test driven through the interface exercises the endpoints the interface uses, with every constraint the front end enforces still in place. An API test constructs requests by hand and exercises every endpoint whether the interface uses it or not, which is where the server trusts something the client was supposed to guarantee.

If your application is a front end over an API, and most now are, scope both and say so in the tender. We name both surfaces in one engagement so the report says which endpoints were tested directly.

An API pentest needs a specification if one exists, credentials or a token for each role, and either a test environment or an agreed production window. The rules of engagement are fixed before any request is sent.

With a specification

An OpenAPI or GraphQL schema gives us the endpoint inventory on day one, so the time goes on testing rather than discovery. We still compare the specification against live traffic, because the two disagree more often than teams expect.

Without a specification

We rebuild one from traffic, by driving the web and mobile clients through a proxy and recording every call. It takes longer, and the gap between what was documented and what is live is itself a finding worth having.

Tokens are needed per role, not per person. A single token cannot show whether one user can reach another user's records, which is the class of flaw this test exists to find.

An API pentest covers REST and GraphQL, and the authorisation questions are the same for both. What changes is where the weaknesses tend to sit and how the endpoint inventory is built.

REST

Every route and method is enumerated, including versions nobody retired, and each object-owning endpoint is tested across roles. Mass assignment, undocumented parameters and identifier enumeration are the recurring classes.

GraphQL

GraphQL shifts the risk without removing it. We test introspection exposure, query depth and cost abuse, batching and aliasing, and resolver-level authorisation, which is where most GraphQL implementations are weakest because a single schema hides many resolvers.

An API pentest takes one to three weeks in most cases, including reporting. The drivers are the endpoint count and the number of roles, and role count matters more than endpoint count.

Authorisation testing scales with roles multiplied by object-owning endpoints, because every one of those endpoints is tested across every role rather than sampled. A small API with five roles takes longer than a large one with a single role.

Rebuilding a specification from traffic adds time at the start. The retest is quoted alongside the initial scope and happens once your fixes have landed.

Yes, an API pentest tests undocumented endpoints wherever we can find them, and finding them is part of the job. An endpoint nobody documented is an endpoint nobody reviewed, and in practice a meaningful share of findings come from exactly there.

We build the endpoint inventory from the specification, from the JavaScript and mobile binaries that call the API, from proxied traffic, and from guessing the routes a framework leaves behind. Old versions and debug routes turn up this way.

The report lists what was in the inventory, so you can see the difference between what your team believed was live and what was actually answering requests.

An API pentest tests for broken object level authorisation and broken function level authorisation by calling every endpoint with the token of each role and checking whether the server noticed. BOLA is the most common critical finding in UAE payment and open banking environments, and both classes are invisible to scanners because the response looks entirely normal.

Object level (BOLA)

An endpoint returns or modifies a record based on an identifier in the request without checking that the caller owns it. Change the identifier and receive somebody else's data. We test every object-owning endpoint across roles, never a sample.

Function level (BFLA)

An ordinary user can call an administrative endpoint simply by knowing it exists, because role separation is reflected in the interface and not enforced server side. We call each privileged function with each lower role's token and record what happens.

An API pentest evidences the technical testing side of Open Banking: consent enforcement, scope handling and authorisation on the flows CBUAE-regulated institutions are examined on. It is not a substitute for the certification process itself, and any provider telling you otherwise is overselling.

What we test is whether a consent granted for one account, one scope or one time window can be used beyond it, whether a token issued for one purpose works for another, and whether a third party can reach records it was never authorised for.

The report gives your examiner the scope rationale, the findings, the owners and the retest evidence. Pair it with the conformance work your programme already requires rather than treating one as the other.

An API pentest generates load only where rate limit testing has been explicitly agreed in the rules of engagement, with volumes and a window fixed first. Nothing that could look like a denial of service happens without you knowing when.

Rate limiting and enumeration are in scope because they decide whether identifiers, accounts or resources can be walked, and at what cost. The testing that answers that question is measured and short, not a flood.

We also identify endpoints expensive enough to be a denial of service in themselves, such as unbounded queries or costly GraphQL resolvers, and report them without exercising them to the point of harm.

An API pentest delivers findings with request and response evidence, severity, reproduction steps, named owners and MITRE ATT&CK mapping, plus an executive summary, a remediation order and a retest once your fixes land.

Each finding carries the exact request that demonstrates it and the response that proves it, so a developer can replay it in minutes rather than reconstruct it from a description. Findings are proved, never asserted.

The retest is quoted at the start so it is a scheduled step and not an upsell, and a signed attestation of testing states the scope, dates, standard and outcome for procurement and auditors.

An API pentest is best run grey box, with the specification and a token per role. That is the default we recommend, and the other two positions are chosen for a specific reason rather than by habit.

Black box

We start with nothing but the name of the target. Against an API this is mostly reconnaissance, because without tokens the authorisation surface, where the serious findings live, is never reached.

Grey box

We start with the specification and a token for each role, the access a legitimate integrator or user would have. It covers the object and function level authorisation checks a black box run never gets to.

White box

We also receive configuration, gateway policies and where relevant source code. It is worth it when the question is completeness of authorisation coverage rather than what an outsider could find.

An API pentest should test through the gateway first, as an external caller would, and then the services behind it where the architecture allows. The gateway typically handles authentication and rate limiting, but object level authorisation is decided in the service, and that is where the findings are.

A service that assumes every request has already been checked by the gateway is trusting something it cannot see. Where internal services are reachable, from a partner network, a mobile client or another tenant, we test whether they still check the caller.

Scoping names which layer each endpoint was tested at, so the report does not imply coverage of a service that was only reached through the gateway's filters.

Our API pentest follows the OWASP API Security Top 10 as the coverage baseline, so object level authorisation, function level authorisation, broken authentication, unrestricted resource consumption and property level authorisation are each tested by name, not folded into a generic web checklist.

The engagement runs in the same six phases as every test we do: gathering information, threat modelling, vulnerability analysis, exploitation, post exploitation and reporting. That structure follows PTES and NIST SP 800-115, and it is why two reports a year apart are comparable.

Token and session handling is tested against the same standard: issuance, scope, expiry, refresh, revocation and whether a token issued for one purpose works for another. Findings are mapped to MITRE ATT&CK so the report speaks the same language as your detection team.