ASVS 5.0 V2.1.1 requires that your documentation defines input validation rules: for each data item, what a valid value looks like. That covers common formats such as card numbers, email addresses and phone numbers, and internal formats too. It is a Level 1 requirement.
Why it matters
You cannot test or review a rule that nobody wrote down. When rules live only in individual developers' heads, different services accept different things, and the gaps become injection and logic bugs. A written rule also gives testers an exact boundary to attack.
How to implement it
Keep a validation table next to the API definition. For each field record the type, allowed characters or pattern, minimum and maximum length or value, whether it is required, and the action on failure.
fields:
email:
type: string
max_length: 254
pattern: "RFC 5322 subset, checked by the shared validator"
quantity:
type: integer
min: 1
max: 1000
order_ref:
type: string
pattern: "^[A-Z]{2}[0-9]{8}$"
If you already publish an OpenAPI or JSON Schema file, that is the document. Generate validation from it so the docs and the code cannot drift.
How to test it
Pick five fields at random. For each, find the documented rule, then send a value just outside it. The application should reject it as documented. Any field with no rule, or a rule that differs from behaviour, is a defect.
Example review
When you review the document, check that each rule says what happens on failure. "Reject with 400 and a generic message" is a rule. "Should be valid" is not. Also include file uploads: allowed types, maximum size and how the type is determined.
Common mistakes
- Documenting formats but not length limits.
- Writing the rules once and never updating them.
- Having a separate document for each service with conflicting rules.
Quick check
Is an OpenAPI schema enough to satisfy this?
Yes, if it states the constraints for each field and is the source the validation code is generated from or tested against.
