Object-level authorization, checked per endpoint
The dominant API flaw is an endpoint that authenticates the caller correctly and then never asks whether this caller owns the object being requested. Change an identifier and you read someone else's record.
The only way to find this is to test every endpoint that accepts an identifier, with a token that should not have access to the object. It is tedious and it is where the real findings are. One endpoint checking ownership is not evidence that the next one does.
What gets exercised
Scope includes the endpoint inventory itself, because an undocumented endpoint is still a live endpoint.
- Authorization on every endpoint, including ones absent from the documentation
- Object-level access control with tokens from a different account and a different tenant
- Token handling: expiry, revocation, signature validation, scope enforcement, refresh flows
- Mass assignment: fields the client should not be able to set
- Schema abuse: type confusion, oversized payloads, unexpected nesting, enum bypass
- Rate limiting and resource exhaustion within the limits in the rules of engagement
Documentation helps, and its absence is a finding
An OpenAPI or GraphQL schema makes the test faster and deeper, because the tester spends the time on authorization rather than on discovery.
If no specification exists, the endpoint inventory is built from your client applications and traffic. The gap between what you believe is exposed and what is actually exposed then becomes one of the report's findings.
GraphQL and REST are tested differently
REST spreads authorization across many routes, so coverage means enumerating them all. GraphQL concentrates it behind one endpoint, so the questions become resolver-level authorization, query depth and cost limits, and whether introspection hands an attacker the whole schema.