An API security testing checklist is clearest as a matrix: for every operation, call it with no credentials, with a valid token and with a token that lacks the needed role, then record what comes back. Around that matrix, test token handling, object access, extra fields and limits.
Build the surface map first
You cannot test what you have not listed. Pull the OpenAPI file if one exists, capture real traffic through a proxy, and look for operations the description omits. OWASP's REST assessment guidance suggests checking common paths for machine-readable descriptions, and treating differences between spec and behavior as leads, not automatic bugs.
The matrix
| Operation | No token | Valid token | Wrong role or scope |
|---|---|---|---|
| GET /orders/ID | Expect 401 | Expect 200 for own object | Expect 403 |
| DELETE /orders/ID | Expect 401 | Own object only | Expect 403 |
| GET /admin/users | Expect 401 | Expect 403 | Expect 403 |
Record the status code, body and whether the operation changed data. A denial should use the documented status, and should not return a server error.
Checklist
- Authentication: tamper with token claims, strip the signature, and send expired and wrong-audience tokens.
- Object access: use two accounts and swap identifiers across read, update and delete.
- Function access: call owner-only or admin-only operations with a low-privilege token.
- Property handling: add fields such as roles or verification flags, then read the object back to see if they stuck.
- Limits: check that throttling applies to login, token and recovery endpoints, and find out what one expensive request costs.
- Errors: confirm failures do not leak stack traces or internal hostnames.
- Inventory: look for old versions and undocumented hosts still reachable.
Notes on the matrix
An operation level security declaration in OpenAPI replaces the root level one rather than combining with it, so check every operation individually. Per-IP rate limits can be bypassed, and an authenticated session should not switch limits off.
Where automation helps
Scanners fuzz and replay well, but they do not know which user owns which object. The object and function access rows usually need scripted tests with two real test accounts.
Try it yourself
Run the API scan and compare which operations returned the unexpected status.
Click through it at your own pace, or open it full screen.
Quick check
How many test accounts do I need?
At least two normal users in different tenants, plus one admin. Two users are what make object access tests possible.
Is a clean scanner run enough?
No. Scanners rarely understand ownership, so access control still needs targeted tests.
Where Safeguard fits
Safeguard offers dependency and SBOM scanning, reachability analysis and policies and gates that can block a pull request, so the libraries behind your app are checked alongside the app itself. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
