API penetration testing explained
An API test is not a web application test with a different word on the invoice. The browser is the thing that was enforcing your rules, and an API test is what happens when you take it away.
An API penetration test in Canada runs $8,000 to $25,000 CAD for a single product API. The money buys somebody checking whether your authorization holds when requests do not come from your own front end. Almost every high-severity API finding published in the last five years reduces to the same thing: the caller was authenticated to make a request and not authorized to make it, and the server answered it.
$8,000 to $25,000 Single product API, CAD
4 to 7 days Base tester days before endpoint count
Per object How authorisation must be checked, not per endpoint
Why the API is a separate engagement
Your web interface only ever sends the requests it was built to send. It hides the button, it filters the list, it validates the field before it posts. None of that is a security control. All of it runs on a machine your user owns. An API test discards the interface and drives the endpoints directly, with a valid token for a low-privilege account, asking the question the front end never asks: what happens if I request identifier 4192 instead of 4191.
Firms that quote a web application test and treat the API as included spend their time in the browser, where the visible functionality is. If your product is consumed by other software, or if a mobile app talks to the same backend, insist that API testing is a named portion of the scope with its own day count. The argument for naming deliverables is on penetration testing services.
What a proper API test covers
| Area | The question being answered |
|---|---|
| Object level authorization | Can one account read or change another account's records by changing an identifier |
| Function level authorization | Can a standard user call an administrative endpoint that is simply not shown to them |
| Property level authorization | Can a user set a field they should not control, for example a role or a price, by including it in the request body |
| Tenant isolation | Can a request scoped to one customer reach data belonging to another |
| Authentication and token handling | Token lifetime, revocation, signature validation, refresh flows, what happens after a password change |
| Rate limiting and resource consumption | Whether an endpoint can be used to enumerate accounts or to exhaust a backend |
| Mass data exposure | Whether the response contains fields the client hides but the server still returns |
| Input handling | Injection into queries, templates, file paths and downstream service calls |
| Business logic | Sequences the API permits that the product does not intend, such as replaying a step or skipping one |
The finding that pays for the engagement
Broken object level authorization is the most common serious API flaw and it is invisible to scanners: a scanner has no way of knowing that invoice 4192 belongs to someone else. It needs two accounts, a tester who knows which identifiers belong to which, and the patience to walk every endpoint that accepts one. If a quote does not mention testing with more than one account, it is not testing this.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
What to give the tester
Hand over everything. Discovery adds nothing here: an undocumented endpoint found by guessing is a lucky find, and the endpoint you forgot to document is the one you most want covered.
| Item | Why it changes the result |
|---|---|
| A current specification, OpenAPI or equivalent | Defines the endpoint list, so coverage can be measured rather than claimed |
| Two accounts per role, in the same tenant | Horizontal authorization testing needs two peers, not one user |
| Two accounts in different tenants | Tenant isolation cannot be tested from inside one tenant |
| A working authentication example | A day lost to token acquisition is a day not spent testing |
| A collection or example requests | Shows the intended sequences, which is what logic testing departs from |
| Rate limit allowances for the test source | Otherwise the tester spends the week being throttled by your own defences |
Ask for coverage reporting against the endpoint list. A good API report says which endpoints were exercised and which were not reached, and why. That is the document your auditor wants, and the difference between a test and a sample.
GraphQL and other shapes
GraphQL changes the surface rather than the questions. Introspection often hands the tester the schema, which is convenient and is not the vulnerability people claim it is. What differs is that authorization has to be enforced per field and per resolver rather than per route, so a single missing check is reachable through many queries. Query depth and complexity also create a resource exhaustion surface that REST does not have, and batching gives an attacker a way to run thousands of attempts inside one request, which defeats rate limiting applied per request.
Older SOAP and XML interfaces bring their own set, principally external entity processing and signature handling. Webhooks and callback endpoints are routinely left out of scope and should not be: an unauthenticated callback that updates a record is an API endpoint regardless of what it is called internally.
What API testing costs
| Scope | Tester days | Typical range |
|---|---|---|
| Single API, under 30 endpoints, two roles | 4 to 6 | $8,000 to $16,000 |
| Single API, 30 to 100 endpoints, several roles | 6 to 10 | $13,000 to $25,000 |
| Several services behind a gateway | 10 to 16 | $22,000 to $40,000 |
| API added to a web application test | 3 to 5 | $6,000 to $12,000 |
Endpoint count is a rough proxy and the number most firms quote on. The better predictor is the number of distinct authorization decisions your product makes, roughly the number of roles multiplied by the number of object types. A product with two roles and four object types is a small test. A product with eight roles, tenant hierarchies and delegated access is not, even if it has fewer endpoints. The cost calculator takes the same inputs, and the scoping questionnaire produces a scope document you can send to several firms so the quotes are comparable.
Get your API scoped
Tell us the endpoint count, the roles and whether tenants are involved, and we will put one scope in front of Canadian firms.
Get matchedCommon questions
Is an API test included in a web application penetration test?
Sometimes in name and rarely in substance. If the API is the same backend the web interface calls, some coverage happens naturally. What does not happen unless it is scoped is the systematic work: walking every endpoint with a second account, testing property level authorization, and checking tenant isolation. Ask for the API portion to appear as its own line with its own days.
Do we need to give the tester our OpenAPI specification?
Yes, and if you do not have one, the test is a good reason to produce it. Without a specification the tester discovers endpoints from traffic and from the client applications, which reliably misses the internal and legacy endpoints that are the most likely to be under-protected. If the specification is out of date, say so and hand it over anyway, because the gaps between it and reality are informative on their own.
Can automated tools test APIs adequately?
They handle injection classes, missing security headers, and some authentication misconfiguration. They cannot test authorization, because that requires knowing which records belong to whom, and that knowledge is specific to your data model. Since authorization is where the severe API findings are, tooling covers the cheaper half of the problem. The wider argument is on vulnerability assessment versus penetration test.
Should we test in production or in staging?
Staging, if it runs the same authorization code and has realistic data shapes with synthetic values. APIs are one of the few places where a staging test is close to as good as production, because the logic is the same code. What breaks the equivalence is a staging environment with authentication relaxed for developer convenience, which turns the whole exercise into a test of something you do not ship.
How does an API test satisfy a compliance requirement?
The same way any other test does: through scope coverage and evidence of remediation. If your product is an API, then an API test is the test of your product, and your auditor will look for the scope statement to match what the report covers. For PCI DSS specifically the requirement is more prescriptive and is set out on PCI DSS penetration testing.