API security testing
Test API permissions and workflow invariants using separate actors, expected outcomes, and minimal reproducible evidence within an authorized scope.
What it means
API security testing checks how an interface behaves when requests violate identity, authorization, data, and workflow assumptions. A specification helps identify operations but is not proof of secure implementation. Testing should cover differences between users, tenants, roles, and versions under an explicit authorized scope.
A practical example
A tester creates records for two test accounts and verifies that neither can retrieve or modify the other's objects. They then examine extra response properties, unsupported methods, repeated requests, and undocumented operations using nonproduction data.
What to check
Build an endpoint inventory and a role-resource matrix. Test object-level and function-level access, validation, response exposure, and business transitions. Record reproducible evidence without retaining unnecessary secrets.
A common pitfall
A successful response does not establish a vulnerability unless the operation violates the intended policy. Conversely, an error status alone may conceal data already leaked in the response body.
Think it through
Why use two separate test accounts?
Answer: They let you test whether object access follows ownership and role relationships rather than simply confirming that a signed-in account can call the API.
Begin with an actor-resource matrix
Imagine a fictional academy API exposes submissions and instructor feedback. Create two learner accounts and an instructor account in a test environment. For each operation, define who may access which object and which state transitions are allowed.
The matrix gives meaning to a result. A successful response is problematic only when it violates the expected policy; a denial may be correct. Include response content and resulting state instead of checking the status code alone.
Follow alternate paths to the same data
Suppose the main submission endpoint checks ownership, but an export or older API version reaches the same records. Inventory those paths rather than assuming one protected route covers the entire resource.
Test only approved operations with non-sensitive data and agreed limits. Repeated calls, background jobs, and asynchronous exports may require separate evidence because the first response can simply accept work for later processing.
Make a finding reproducible and bounded
A useful report names the test actor, target object, request conditions, expected decision, observed response, and actual effect. Redact live secrets and keep only the minimum data needed to demonstrate the issue.
For a lab exercise, define an authorized read, a cross-account read that must fail, an unsupported state transition, and a duplicate update. Explain which observation would establish each outcome. Then fix one permission failure and retest the relevant allowed and denied cases. This produces evidence of the intended control, rather than a collection of scanner alerts or successful requests without a business rule to interpret them.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: REST Assessment