API testing
How we test REST and GraphQL APIs against their documentation and their real behaviour: authorization per endpoint, data exposure, mass assignment, rate limits and versions.
Test areas
Inventory3 checks
- Endpoints in the supplied OpenAPI or GraphQL schema
- Endpoints seen in client traffic but missing from the schema
- Older versions and internal routes that remain reachable
Authorization per endpoint3 checks
- Object, function and property checks on every route
- Consistency between REST and GraphQL access to the same data
- Machine-to-machine tokens and their scopes
Data exposure3 checks
- Responses returning more fields than the client uses
- Errors and debug output revealing internals
- Pagination and filters that widen access
Input and mass assignment3 checks
- Fields accepted on create and update compared with the schema
- Type, range and format validation on the server
- Injection in filters, sorting and search parameters
Resource limits3 checks
- Rate limits on authentication and expensive operations
- GraphQL depth, complexity and batching limits
- Upload sizes and long-running requests
Documentation and behaviour
An API has two descriptions: the schema your team published and the behaviour the server actually exhibits. Testing compares them. We start from the OpenAPI or GraphQL schema you supply, then watch what the web and mobile clients really call. Differences, such as undocumented endpoints, older versions still reachable or fields the schema does not mention, are recorded and tested.
Authorization, endpoint by endpoint
Every route gets the checks described in the authorization chapter: object ownership, role permissions and field-level access. APIs make these easy to test systematically and easy to get wrong, because each endpoint makes its own decision. Where the same data is available through REST and GraphQL, we check that both apply the same rules.
Data exposure and mass assignment
APIs often return whole objects and leave the client to show what it needs. We look for fields a role should not receive, in normal responses, exports and error messages. In the other direction, we check whether endpoints accept fields the client should not be able to set. The sample report includes a synthetic example where a profile update on api.example.com accepted a role field.
Limits
Authentication endpoints, password resets and expensive operations need rate limits. GraphQL needs limits on query depth, complexity and batching. We test that limits exist and apply per account and per source, within the rate ceilings agreed in the rules of engagement. Load testing is not part of a penetration test unless separately agreed.
Versions and lifecycle
Old API versions are a common blind spot. A fix applied to version two may be missing from version one, which is still reachable. We test every version in scope and note any that should be retired.
What evidence looks like
Each API finding records the endpoint, method, version, the token and role used, the request and the relevant part of the response. Evidence uses synthetic data and documentation domains. Where the issue affects a family of endpoints, the report lists them so your engineers can fix the pattern rather than one route.
What this chapter does not cover
- Coverage of undocumented endpoints depends on what client traffic reveals during testing.
- Partner and internal APIs are covered only if listed in the scope record.
- Load and denial-of-service testing are excluded unless separately agreed.
Get a fixed quote for your release.
A short form about the product and the deadline. We reply with scoping questions, then a fixed written quote.