ASVS V6.1.1 asks you to document how rate limiting, anti automation and adaptive response protect against credential stuffing and password brute force, including how each control is configured and how you avoid letting an attacker lock real users out. It is a Level 1 requirement.
The goal is not paperwork. Anyone reviewing the application, from a new engineer to an external tester, should be able to answer a few questions from the document alone: what stops a million login attempts, what stops one account being guessed, and what stops an attacker from using your defenses to block a customer?
Why it matters
Controls that live only in someone's head drift. A document gives reviewers something to verify against, and it is the reference for V6.3.1, which asks whether the controls match.
Credential stuffing is now the most common way accounts are taken over. Lists from unrelated breaches are tried automatically, and even a tiny success rate means thousands of accounts at scale. Brute force against a single account is rarer, but it still happens against admin users.
The second half of the requirement matters just as much. A defense that locks accounts after a few failures sounds safe, yet an attacker can lock out your CEO at will or lock every customer before a product launch. Your document must show that you thought about that and chose a design that avoids it.
How to implement it
Write a short page per authentication endpoint. Include:
- Limits per account, per IP and per device, with the numbers.
- What happens at each threshold: delay, challenge, step up, or notification.
- How lockout works and why it cannot be abused. For example, soft throttling of the attacker's source instead of hard locking the victim's account.
- Where the settings live and who can change them.
- What you log and who watches the alert.
A table is enough:
Endpoint Limit Response
POST /login 5 fails / 15 min / acct Exponential delay, notify user
POST /login 50 fails / 10 min / IP CAPTCHA, then block 30 min
POST /reset 3 / hour / acct Silent drop, same message
Describe the threat model in two sentences, then the controls in layers:
- Rate limits by account, by source address and by device or fingerprint.
- Anti automation: challenges, proof of work or bot scoring on the login and reset forms.
- Adaptive response: stricter checks for unfamiliar devices, impossible travel or known bad networks.
- Notification: users learn about suspicious attempts.
For each layer include the default values, the configuration file or console where they live, the person who can change them, and how a change is reviewed. State clearly what is not covered, for example distributed attacks that stay under every threshold.
How to test it
Ask someone outside the team to read the page and reproduce the behavior with a script against staging. If the numbers differ, one of them is wrong.
Have a tester follow the document without help from the authors and try to reach each stated threshold. Record where behavior and document disagree, then fix whichever is wrong. Repeat after any change to the login flow, the identity provider or the gateway.
Common mistakes
-
Documenting a lockout that lets anyone disable a victim account.
-
Listing controls without values.
-
Leaving out the reset and registration endpoints.
-
Writing the document after the fact so it describes the plan, not the code.
-
Burying lockout rules in a runbook that the developers never see.
Quick check
Why mention malicious lockout?
Because a naive hard lock turns your defense into a denial of service tool against a named user.
