ASVS 5.0 V2.1.3 requires that you document the expectations for business logic limits and validations, both per user and across the whole application. It is a Level 2 requirement, and it is the input for V2.3.2, where those limits must actually be enforced.
Why it matters
Limits that are not written down are not enforced consistently. Nobody can tell whether a user creating 10,000 projects, or one account moving a million in a day, is abuse or normal use. Fraud, quota exhaustion and cost attacks all live in that blank space.
How to implement it
For each function that changes state or uses a costly resource, record the limit, its scope, and what happens when it is hit.
| Function | Per user | Global | On breach |
|---|---|---|---|
| Create project | 50 | 100,000 | 409 with message |
| Password reset email | 5 per hour | 2,000 per hour | 429 |
| Payout | 5,000 per day | 2,000,000 per day | Hold for review |
Have product, security and finance sign off, and review the table whenever a feature ships.
How to test it
Pick three rows. Read the limit, then try to exceed it by one using a normal account. The documented outcome should occur. A limit that cannot be found, or that behaves differently than written, is a finding.
Who owns the numbers
Assign an owner for each limit, usually the product manager for the feature, with security as a reviewer. Limits change as the business grows, and a stale table is as bad as a missing one, so add the review to your release checklist.
Common mistakes
- Documenting only technical rate limits, not business ones such as daily transfer caps.
- Having per user limits but no global ceiling.
Quick check
Why list global limits as well as per user limits?
Many accounts, each under its own cap, can together exhaust a shared resource.
