Good security acceptance criteria for a new API endpoint are testable statements about authentication, authorization, input limits, error output, logging and abuse limits. Each one should pass or fail when a tester tries it. Ten short criteria, written before coding, cover most of what goes wrong.
Why endpoints deserve their own list
A new endpoint is a new way in. The OWASP Application Security Verification Standard describes itself as a basis for testing technical security controls and as a list of requirements for secure development. You do not need the whole standard on every story, but its chapters are a good source when writing criteria for an endpoint.
Ten criteria to copy
Edit the wording to fit your product.
| # | Area | Criterion |
|---|---|---|
| 1 | Authentication | A request without a valid credential returns an authentication error and no data |
| 2 | Authorization | A user without the required role gets a denial |
| 3 | Object access | A user cannot read or change another user's record by changing an identifier |
| 4 | Input validation | Missing, malformed, oversized and wrongly typed fields are rejected with a clear error |
| 5 | Output | The response contains only the fields the caller needs |
| 6 | Errors | Errors do not reveal stack traces, file paths or internal names |
| 7 | Rate limits | Repeated calls beyond the agreed limit are refused |
| 8 | Logging | Successful and denied calls are logged with caller and action, without secrets or personal data |
| 9 | Transport | The endpoint is reachable only over an encrypted connection |
| 10 | Documentation | The API description lists the endpoint, its auth requirement and its error responses |
How to write them well
- Name the observable result. "Returns a 403" can be tested. "Is secure" cannot.
- One behavior per line. If a line has "and" in it, consider splitting it.
- Include the negative case. Most security bugs live in what should not work.
- Use real roles. Name the roles in your product, not "unauthorized user".
- Tie each line to a test. If nobody can describe the test, rewrite the criterion.
The object access criterion matters most
Number 3 is often missed. An endpoint may check that the caller is logged in and has the right role yet still let them fetch any record by guessing an identifier. Test it with two accounts: one requests the other's record and must be refused.
Where each criterion gets checked
- Criteria 1 to 4 and 7 can be tested automatically in the test suite.
- Criteria 5 and 6 are suited to review and API tests.
- Criteria 8 and 9 belong in review and deployment checks.
- Criterion 10 is a review step on the pull request.
NIST's Secure Software Development Framework asks teams to document security requirements for the software they build and to test executable code, recording and triaging findings. Acceptance criteria are the story-level form of both.
Keep it short
Ten lines per endpoint is a ceiling, not a target. Put what applies to every endpoint, such as transport encryption, in the definition of done and keep only the endpoint-specific lines in the story.
Safeguard offers API security scanning, which can check endpoints against many of these areas in a test environment. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. See how an API scan reports on authentication and access findings, and compare it with the criteria above.
Quick check
Should every endpoint have all ten criteria?
Not always. Shared rules such as encryption belong in the definition of done. Keep story-level criteria for what is specific to the endpoint.
What is the most commonly missed criterion?
Object access: confirming that one user cannot read or change another user's record by changing an identifier.
Sources
- OWASP Application Security Verification Standard
- NIST SP 800-218, Secure Software Development Framework 1.1
Last reviewed: 19 October 2026.
