Direct answer
An API security test case needs a caller, an operation, a known test object, an expected permission decision and observable evidence. The downloadable matrix gives you eight starting cases, including a positive control. Replace the examples with your application's actual access policy before running any checks.
Download API test cases (CSV)Set up two accounts and two workspaces
Create a staging workspace for tenant A and another for tenant B. Give each a disposable record with recognizable, non-sensitive contents. Within tenant A, create a viewer and an administrator. This fixture lets you distinguish ownership failures from role failures without probing unrelated records.
Record the build, API base URL, account aliases and approved scope beside the matrix. Store credentials in your approved secret store, never inside the CSV. The example routes are placeholders; the download does not send requests or run a scanner.
Reference: OWASP API Security Top 10.
Run a valid request before each denied case
Start with an owner reading their own test invoice. If that fails, a later denied response tells you little: the record may be missing or the session expired. Next, change only the test identity or object required by the case. Compare the response and resulting state with the written permission policy.
- Authentication: an anonymous caller must not read a private record.
- Ownership: account B must not read A's unshared invoice.
- Roles: a viewer must not perform an administrator-only update.
- Tenant isolation: changing a workspace identifier must not cross the membership boundary.
Check property access, limits and revocation
An endpoint can protect the record while accepting a privileged field such as role or approval status. Use a disposable fixture to confirm forbidden fields are rejected or ignored, and inspect the resulting state. Keep an allowed field update as a control.
Agree a small request budget before checking rate limits. Record the expected threshold and time window; do not infer a missing control from a handful of successful calls. Remove a test membership and check subsequent access against the product's documented revocation timing.
Reference: OWASP API Security Top 10.
Record evidence and retest the boundary
Every row starts as Not run. Use Pass for expected behavior, Finding for a demonstrated policy violation, or Unchecked with a reason when a fixture is unavailable. A 200 response alone is not proof of unauthorized access: inspect the protected data or state change.
Assign confirmed findings to an owner and retest the same identity-object-action combination after remediation. Repeat the positive control so the fix does not simply deny every request. Add export, batch and attachment routes where they reach the same resource.
- Save redacted evidence references, not session tokens.
- Record expected and actual behavior separately.
- Keep the tested build and retest date with each result.
Assessment limits
These examples are a starting matrix, not complete OWASP coverage or proof that an API is secure. Business workflows and integrations need additional cases. This is a planning resource, not a claim that MyPentest automates every listed check.
Frequently asked questions
Can I open this checklist in Excel?
Yes. Open or import the CSV in Excel, Google Sheets or your issue tracker. Preserve separate columns for expected behavior, observations, status and evidence.
Must denied requests return 403?
No. Some applications use 404 to avoid revealing an object. Verify protected data and actions remain unavailable using the application's documented response policy.
Is this an automated test suite?
No. It is a downloadable planning matrix. Implement the cases in your authorized test environment or use them to review assessment coverage.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.