What Does an API Penetration Test Actually Cover?
An API penetration test covers authentication, authorisation logic, input handling and the business rules sitting behind each endpoint, all tested by hand against a running environment. It is not a scan of your website. A tester works through your API documentation, then goes hunting for the endpoints that never made it into the documentation. If you run a SaaS platform or a mobile app, most of your real risk lives here.
What an API penetration test includes
An API penetration test is a manual assessment of every exposed endpoint, the authentication model in front of it and the data it hands back to a caller who should not have it. Testing starts with whatever specification you can supply, usually an OpenAPI file or a Postman collection. The tester then proxies traffic from your own client and rebuilds the request set from what it actually sends, which is where undocumented routes surface. Older versions left running at /api/v1 while the front end moved to /api/v2 are common, and they often keep the permissions model they shipped with.
The flaws automated tools cannot find
Scanners find injection and misconfiguration. They do not find broken authorisation, because no tool knows whether invoice 4102 belongs to the customer asking for it. The OWASP API Security Top 10, in its 2023 revision, puts Broken Object Level Authorization at number one for exactly that reason. The test is unglamorous: authenticate as tenant A, request an object identifier belonging to tenant B, and see whether the server returns 200 with live data. We also check mass assignment, where adding a field such as “role”: “admin” to a profile update request quietly changes something the user interface never exposes.
“The endpoint that causes the breach is almost never the one in the documentation. We regularly find an old API version still answering requests months after the front end moved on, missing the authorisation checks that were bolted on later. Ask your developers for a list of every deployed version before you scope the work, not just the one they are proud of.”
William Fieldhouse, Director, Aardwolf Security Ltd
How the work is scoped
You should scope an API engagement by endpoint count and role count, not by counting applications. Fifty endpoints with one role is a smaller job than fifteen endpoints with four roles and a multi-tenant model, because every authorisation boundary has to be walked in both directions. Give the tester at least two accounts per role, ideally in separate tenants, or the interesting findings cannot be proved. Confirm the authentication method early too, since OAuth 2.0 with short-lived tokens behaves nothing like a static API key that has never been rotated. Rate limiting matters as well: if your WAF blocks the tester after forty requests, you are paying consultant days for a fight with your own kit. Most providers offering API penetration testing services will ask for an allowlisted source address before day one.
What you should get at the end
You should expect a report that gives the exact request and response proving each finding, not a paragraph of theory. Developers fix things faster when they can paste the request into their own client and watch it work. Look for a risk rating that reflects business context rather than a raw CVSS number, and remediation advice written against the framework your team uses. A free retest window is worth negotiating for. If a provider will not show you a sample report before you commit, that tells you something. When you ask for a penetration testing quote, send the endpoint count and role model with the enquiry and you will get a realistic figure rather than a placeholder.
Frequently asked questions about API penetration testing
These questions come up in almost every scoping call we run with UK development teams.
How long does an API penetration test take?
Most API tests run between three and six consultant days. A small internal API with one role can be covered in two, while a multi-tenant platform with hundreds of endpoints runs longer.
Do testers need your source code?
No. Grey box testing with documentation and working credentials is the normal approach, and it finds authorisation flaws faster than reading code does. Source code review is a separate exercise worth adding when the API handles payments or health data.
Can the test run against production?
Yes, and it often should, because staging rarely carries the same data or integrations. Agree a change freeze, take a backup and keep a technical contact reachable while testing is live.
