API Security Testing
API penetration testing for REST, GraphQL and SOAP services. We test the API directly with every user role, because a check the front end makes means nothing if the server does not make it too.
What the Test Covers
An API penetration test goes straight to the interface your web app, mobile app and partners all talk to. Every endpoint in scope is tested with and without authentication, as each user role, with the OWASP API Security Top 10 as the baseline. REST, GraphQL and SOAP are each tested in their own way. GraphQL in particular exposes more than most teams expect, through introspection, deeply nested queries and resolvers that check permissions on the parent object but not on the fields beneath it.
Where the Serious Findings Are
Object level authorisation, almost every time. An endpoint takes an ID and returns the record without checking it belongs to the caller. Change the number and you get someone else’s invoice. Close behind are function level problems, where an ordinary user can call an admin endpoint because nothing on the server stops them. Then responses that return the whole database record when the screen only shows a name. Rate limits, mass assignment and verbose errors fill out the rest. None of it shows up from the front end, because the front end never asks.
Scoping a Large API
Fifty endpoints is not fifty times the work of one. Most APIs repeat a handful of patterns, such as list, read, create, update and delete, with the same authorisation logic behind each. Scoping starts by grouping endpoints by pattern and role. Each pattern is tested thoroughly, then every endpoint is checked for the places where it breaks from the pattern. That is usually where the findings are. A specification or a collection of example requests makes the grouping quick. Without one we build the map from traffic.
What You Get From the Test
Every Role Tested
Each endpoint called as every user role, so one customer reading another customer’s data does not go unnoticed.
Proof You Can Replay
Every finding comes with the exact request that proves it, ready for your developers to reproduce and fix.
Coverage Beyond the Front End
Endpoints, parameters and versions the interface never uses, tested as directly as the ones it does.
Findings Mapped to OWASP
Each issue tied to the OWASP API Security Top 10, which supports GDPR, ISO 27001 and PCI DSS evidence.
How the Test Runs
We agree the scope in writing first: the APIs, endpoints, environments and user roles. Documentation helps but is not essential. Unauthenticated testing comes first, looking at what answers without a token and whether old versions or debug endpoints are still exposed. Then each role is tested against every other role by swapping identifiers, calling functions above its privilege and sending fields it should not be able to set. Input handling, rate limits and error responses are checked throughout. Anything critical is reported the moment it is confirmed.
At a Glance
Documentation Review
Specification, endpoints, authentication flows and parameters mapped, or built from traffic.
Unauthenticated Testing
What answers without a token, including old versions and debug endpoints.
Authenticated Testing
Every role tested against the others for object and function level authorisation.
Business Logic Testing
Rate limits, mass assignment, unexpected inputs and the order operations happen in.
Report & Retest
Risk rated findings with proof of concept requests. Free retest included.
Findings appear in your client portal as we find them. Our day rate is published on the pricing page.
You May Also Be Interested In
Frequently Asked Questions
What types of APIs do you test?
REST, GraphQL and SOAP services, whether they are internal, used by your own apps or exposed to partners and the public. The OWASP API Security Top 10 is the baseline for every assessment. GraphQL gets extra attention on introspection, query depth and authorisation at field level, because that is where it differs most from REST.
Do I need to provide API documentation?
It helps but it is not essential. An OpenAPI specification or a collection of example requests lets us map the API quickly and spend more of the time testing. Without one we build the map from traffic captured while the application is in use.
How is API testing different from web application testing?
A web application test works through the browser interface. An API test goes underneath it and calls the server directly. The most common serious API issues, such as broken object level authorisation and excessive data exposure, are invisible from the interface because the interface never sends those requests. Where an application has both, we usually test them together.
Can you test APIs that require authentication?
Yes. Most of the value is there. We work with you to set up test accounts at each access level, then check whether any of them can reach data or functions that belong to another user or role.