ASVS V6.3.4 requires that, when the application has several authentication pathways, none are undocumented and the same security controls and authentication strength apply on all of them. It is a Level 2 requirement and the verification side of V6.1.3.
Why it matters
Old versions of an API, a debug login, a partner token endpoint or a mobile login often skip rate limits and MFA. Attackers enumerate paths. You need to find them first.
An authentication pathway is any route that results in a session, token or credential for a user. Once an application has been around for a while that list grows. There is the main login, a legacy version of the API, a partner integration, an internal support tool that can impersonate a customer, a debug flag, a mobile token endpoint and a recovery flow. Every one of them is a place where a control may be missing.
Attackers do not need to beat your best defended door. They need the least defended one, and automated tools will find it by testing versions and paths.
How to implement it
List all routes that create a session or token and compare them with the documentation. A quick route dump helps.
# Flask example: print routes that look like authentication
for rule in app.url_map.iter_rules():
if any(k in rule.rule for k in ("login", "auth", "token", "session", "sso", "signin")):
print(rule.methods, rule.rule, rule.endpoint)
Put the shared controls in one place, such as middleware or the identity provider, rather than copying them per route. Remove or block legacy versions, and have the gateway deny unknown paths.
Start with discovery from three directions: static code, runtime traffic and infrastructure configuration. In code, search for functions that create sessions or sign tokens. In traffic, look at the gateway logs for paths that return a Set-Cookie or a token field. In configuration, check the identity provider for applications and clients that can issue tokens.
Then centralize enforcement. A shared authentication service or middleware applies rate limits, MFA, risk checks, logging and session rules, so a new route inherits them by default.
Finally, close the gaps. Remove legacy versions, restrict internal tools to a private network with strong sign in, and require every new route that issues credentials to be registered in the authentication inventory. A test that fails when an unknown route issues a token keeps the list honest.
def test_no_unregistered_auth_routes(app, registry):
found = {r.rule for r in app.url_map.iter_rules() if r.endpoint in TOKEN_ISSUERS}
assert found <= set(registry), f"undocumented auth routes: {found - set(registry)}"
How to test it
Run an authenticated crawl and an API discovery scan, then diff the paths that issue credentials against the doc. Test each with a stolen password only and confirm MFA, rate limits and logging all apply.
Take the inventory and run the same battery against each pathway: wrong password burst, valid password without second factor, session fixation, replayed token and recovery bypass. Compare outcomes. Differences show where enforcement is inconsistent.
An API discovery scan is a good complement, because it finds routes that no one wrote down. Run it with and without credentials, and look at old version prefixes and framework default endpoints.
Common mistakes
-
Trusting that v1 of the API is unused.
-
Per route copies of the throttle that drift.
-
Developer shortcuts that survive into production.
-
Trusting network location, so an internal route skips MFA.
-
Giving support staff an impersonation tool that issues a full session without audit.
-
Forgetting service to service tokens that are minted by a person with a password.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Where should the controls live?
In shared middleware or the identity provider, so every pathway inherits them.
