How is API testing different from web application testing?

A web application test follows the screens and the requests those screens make. An API test treats the interface as the product. There may be no browser at all. The questions are which objects a token can read, which methods ignore the owner of the object, and which partner integration trusts more than the design intended. The two overlap, and we will say when one engagement should cover both.

Do you test GraphQL as well as REST?

Yes, when GraphQL is what you run. Introspection, query cost, authorization on fields, and mutations that skip a check the REST cousin enforces are ordinary findings. We name the endpoint and the operation. We do not treat a schema dump as a finding by itself.

What do you need from us before testing starts?

A specification or a collection of real calls, accounts or tokens for each role in scope, and a stable environment. If the API is only documented by the mobile or web client that calls it, say so. We can work from the client, and the scope should say that the client is how we discover the surface.

Will you fuzz every parameter?

Fuzzing is a way to cover ground. It is not the conclusion. We use it where it is useful and allowed, and we turn it down where it would create junk data you then have to clean up. The findings in the report are the ones we confirmed, not the raw tool output.

Can you test a partner or public API we consume but do not own?

No. We test APIs you own or are allowed to authorize in writing. A third-party API is out of scope even if your application calls it. We can still report that your application trusts a response more than it should. We will not attack the other party's service.

API Penetration Testing (REST & GraphQL)

What is API penetration testing?

API penetration testing is an authorized test of the interface itself: the routes, queries, and messages your applications and partners send. The question is what a caller can do with a token, a key, or no credential at all, beyond what the design allows. The answer is a set of confirmed requests, not a list of headers a scanner disliked. It applies to REST, GraphQL, and the older HTTP APIs that are still in production because a customer still calls them.

What we test

Authorization is the center of the work. We look at object-level access, function-level access, and the places where one tenant’s identifier is accepted in another tenant’s session. Authentication, token lifetime, and the difference between a user token and a partner credential are in scope. So are mass assignment, injection into queries the API builds, server-side request forgery through a URL the API fetches, and rate limits that exist on the documentation and not on the route. For GraphQL we look at introspection, field authorization, and mutations that bypass a check the interface claims to enforce.

The OWASP API Security Top 10 is the map we use so a reader can see what was covered. It is a map, not a promise that every numbered item will produce a finding. Where the API sits behind a web client, we still test the calls the client makes, and we will tell you if a web application penetration test is the engagement that matches the way the product is actually used.

You provide credentials for each role, a non-production environment when you have one, and any allow-list our source addresses need. We do not ask for a production database. If a request returns personal data, we keep the smallest excerpt that proves the issue and we stop.

Approach and standards

Grey-box is the usual shape. A specification, a gateway collection, or a few recorded calls is enough to start, together with the accounts that represent real callers. Black-box, with only the public documentation, answers a narrower question and we will say so if that is all we were given. White-box review of the handlers is available when you want the fix pointed at a function.

We follow the same methodology as every other engagement: scope, rules, testing, report, retest. Destructive calls and denial of service are out unless the rules allow them in writing. Unauthenticated scanning of a host you did not name is out even if the API gateway answers on it.

Clients sometimes ask for the results beside PCI DSS, ISO 27001, or a SOC 2 control. We will map a finding to a control you name. The map is not an attestation. If the real question is coverage across many hosts rather than depth on one API, a vulnerability assessment is the better tool.

How long it takes and what affects the price

One API with a handful of roles is often four to eight testing days after the rules are signed, then reporting. A platform with several products, a partner tier, and an admin API is longer. GraphQL with a wide schema takes more time than a small REST surface with the same number of roles, because the authorization question repeats on fields. The contract names the window. We do not publish a rate card.

What moves the price is the number of roles and tenants, whether partner credentials are in scope, how much of the surface is documented, and whether the environment is shared with production traffic. A test that has to be careful of live customers is a different piece of work from a test against an empty staging tenant.

What you receive

The report includes the request that worked, the role it was sent as, what it returned, and what to change. Leadership gets a short account of which trust boundaries failed and which held. You also receive the scope you signed and a retest note after the fixes. The documents are described on the methodology page. We do not invent a sample that pretends to be someone else’s engagement.

When to choose this

Choose this when callers talk to you through an API and the user interface is thin or absent. Choose web application penetration testing when the screens and the session are the product and the API is an implementation detail of those screens. Choose mobile app penetration testing when the client stores data and the question includes the device, not only the server. If the API and the mobile client both matter, we will scope them together rather than pretend one report covers the other. Start with the contact page and say which interface holds the data.