API risk lives in how the product works.
Checklists help establish coverage, but the most damaging API weaknesses often depend on roles, object relationships, transaction state, and assumptions made by the application.
Authorization needs a data model
Object-level authorization testing starts by mapping users, tenants, roles, resources, and relationships. Changing a numeric identifier is only one test. An assessor should also vary nested identifiers, indirect references, export jobs, bulk operations, file keys, and parent-child relationships to determine whether the server consistently enforces ownership and scope.
Function-level authorization deserves the same attention. Administrative behavior is sometimes exposed through alternate HTTP methods, legacy versions, mobile endpoints, or fields that are hidden by the user interface but accepted by the API.
Workflows can be valid and still be unsafe
Many high-impact API weaknesses do not look like malformed requests. The attacker uses a legitimate operation at the wrong time, in the wrong sequence, or at a scale the product did not anticipate. Examples include replaying a one-time action, bypassing an approval step, manipulating a quantity after a price calculation, or automating a resource-intensive business flow.
Testing should model state transitions and invariants: what must be true before an operation, what must remain true afterward, and which actor is allowed to cause the change.
Inventory and protocol differences create blind spots
Older versions, undocumented endpoints, partner APIs, GraphQL schemas, and internal services can remain reachable after the primary interface is hardened. Compare control behavior across every deployed surface. Authentication, authorization, validation, and rate limits should not become weaker because a request arrived through a different protocol or client.
Test the complete trust boundary
Tokens, session revocation, backend integrations, error behavior, sensitive data handling, and resource consumption should be evaluated together. A useful API security report connects the request and response evidence to the affected business action, explains the preconditions, and gives engineers a server-side control they can verify during retesting.