Home / Attacks & tests / Authentication Testing: Definition & Key Focus Areas
13 test cases
Authentication Testing: Definition & Key Focus Areas
Authentication testing establishes whether the application reliably determines who is making a request, and whether the mechanisms around that decision — credential transport, lockout, recovery, second factors and alternative channels — are as strong as the primary login. Authentication is usually attacked at its edges rather than at the password prompt.
What an attacker is trying to achieve
The attacker wants a valid session belonging to someone else, and will take the cheapest route to it: a recovery flow that does not verify, a second factor that can be skipped, a mobile endpoint that never received the lockout policy, or a response that confirms which usernames exist. Guessing the password is the option of last resort.
Test cases
13 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
WEB-ATHN-01 Credentials Transported over an Encrypted Channel
Objective — Determine whether credentials and session material are ever transmitted in a form an observer on the network could read or reuse.
How it is tested — Capture the full authentication exchange for every channel — the primary web form, any mobile or API client, and password change and recovery flows. Confirm each is carried over TLS, and that no plaintext variant of the endpoint accepts the same submission. Check whether credentials appear in URLs, in referrer headers, in redirect targets or in client-side logging, all of which survive the encrypted channel and reappear elsewhere.
Prerequisites — The ability to observe requests from each client type; a test account whose credential may be exposed during testing.
Indicators — A credential submitted over plaintext; a plaintext endpoint accepting the same submission; a credential or token appearing in a URL, referrer or log rather than only in a request body.
Coverage — WSTG-ATHN-01V9.1.1CWE-319CWE-522
Depth — Hybrid Confirming TLS is automated; finding the credential in a referrer or a client-side log is manual.
WEB-ATHN-02 User Enumeration
Objective — Determine whether the application discloses which identifiers correspond to real accounts, through any of the flows that accept an identifier.
How it is tested — Submit known-valid and known-invalid identifiers to login, registration, password recovery, and any invitation or availability check, and compare the responses on message text, status code, redirect target, and response time. Timing matters particularly where a valid identifier causes a password hash to be computed and an invalid one does not. Repeat against each channel, since a mobile or API endpoint frequently returns a more candid error than the web form.
Prerequisites — One identifier known to exist and one known not to; the ability to issue enough requests for a timing comparison; every authentication channel enumerated.
Indicators — Different messages, codes or redirects for valid and invalid identifiers; a consistent timing difference; a registration or availability check confirming existence directly.
Coverage — WSTG-IDNT-04CWE-204CWE-203
Depth — Hybrid Message differences are found automatically; timing differences need controlled repetition and a statistical rather than a single-shot read.
WEB-ATHN-03 Account Lockout
Objective — Determine whether repeated failed authentication is constrained, and whether the constraint protects the account without itself becoming a means of denying service.
How it is tested — Submit successive failed attempts against a disposable account, recording the threshold, the lockout duration and whether the account or the source address is the subject of the restriction. Establish whether the counter resets on success, on time, or not at all. Test whether the restriction can be evaded by varying source address, session, casing of the identifier, or by moving to a different authentication channel. Determine whether a third party can lock a known account deliberately.
Prerequisites — A disposable account in a non-production environment; permission to trigger lockout; more than one source address where source-based restriction is claimed.
Indicators — No threshold; a counter that never resets, or resets on any request; restriction evaded by changing channel or identifier casing; an account lockable by anyone who knows the identifier.
Coverage — WSTG-ATHN-03V2.2.1CWE-307CWE-645
Depth — Hybrid Threshold discovery is automated; the evasion cases and the denial-of-service consequence require deliberate construction.
WEB-ATHN-04 Authentication Bypass
Objective — Determine whether an authenticated state can be reached without presenting valid credentials, through direct request, parameter manipulation, or trust placed in client-supplied assertions.
How it is tested — Request post-authentication routes directly without a session, and with a session that has begun but not completed authentication. Manipulate any client-visible indication of authentication state — parameters, cookies, tokens and their claims — and determine whether the server re-derives the state or trusts what it is given. Where tokens are used, test unsigned and altered-algorithm variants, and tokens issued for another audience or a different environment.
Prerequisites — The post-authentication route list; a valid session for comparison; the ability to modify tokens and cookies before they are sent.
Indicators — A protected route responding without authentication; a client-modifiable value determining identity; a token accepted with an altered signature, algorithm or audience.
Coverage — WSTG-ATHN-04WSTG-SESS-10V3.2.1CWE-287CWE-288
Depth — Manual The productive cases depend on how this application represents authentication state, which is specific to it.
WEB-ATHN-05 Remember-Me Functionality
Objective — Determine what a persistent authentication feature actually stores, how long it remains valid, and whether possession of it is equivalent to possession of the credential.
How it is tested — Enable the feature and examine the persistent artefact it creates: whether it encodes the identifier or credential recoverably, whether it is bound to the device or session, and how long it remains valid. Determine whether it survives password change, logout, and account suspension — each of which should invalidate it. Establish whether the artefact alone grants a fully privileged session or a reduced one requiring re-authentication for sensitive operations.
Prerequisites — An account permitting the feature; the ability to inspect and replay stored cookies; a second client to test whether the artefact is portable.
Indicators — A credential or identifier recoverable from the artefact; validity surviving password change or logout; the artefact usable from a different device; a full-privilege session granted without re-authentication.
Coverage — WSTG-ATHN-05V3.3.1CWE-539CWE-522
Depth — Manual Requires the password-change and logout sequences to be run with the artefact retained, which is a deliberate ordering.
WEB-ATHN-06 Browser Cache Weakness
Objective — Determine whether authenticated content and credentials remain retrievable from the client after the session ends, from cache, history or autocomplete.
How it is tested — Review cache-control directives on authenticated responses, particularly those carrying personal or financial data. After logging out, use browser history navigation to determine whether previously rendered authenticated pages are re-displayed from cache without a new request. Examine whether credential fields permit autocomplete, and whether sensitive values are written to browser storage that outlives the session.
Prerequisites — A browser with cache and history retained; an authenticated session that can be ended; at least one page displaying data specific to the account.
Indicators — Authenticated pages re-rendered after logout without a server request; cache directives absent or permissive on sensitive responses; credentials retained by autocomplete; sensitive values persisted in browser storage.
Coverage — WSTG-ATHN-06V8.2.1V8.2.3CWE-525
Depth — Manual Depends on real browser behaviour after logout, which a header check alone does not establish.
WEB-ATHN-07 Password Policy Strength
Objective — Determine what the application will actually accept as a password, as distinct from what its guidance says it requires.
How it is tested — Submit candidate passwords at the boundaries of every stated rule through each route that sets a password — registration, change, administrative reset and recovery — since these are frequently validated by different code. Test minimum and maximum length, whether long passphrases are accepted rather than truncated, whether known-breached and trivially common values are refused, and whether the identifier itself is accepted as the password.
Prerequisites — An account whose password may be changed repeatedly; access to every password-setting route including the administrative one.
Indicators — A rule enforced on one route and not another; a common or breached value accepted; a password silently truncated; the username accepted as its own password.
Coverage — WSTG-ATHN-07V2.1.1CWE-521CWE-1391
Depth — Hybrid Candidate submission is automated; the finding that usually matters is the inconsistency between routes, which requires testing all of them.
WEB-ATHN-08 Password Security Mechanisms
Objective — Determine how credentials are protected in storage and in use, so far as that is observable from outside, and whether the surrounding controls behave as their design intends.
How it is tested — Establish whether the application ever returns a stored password in any form, including to administrators. Examine responses and timing for evidence of the comparison performed. Determine whether password change requires the current password, whether reuse of recent passwords is refused, and whether changing the password invalidates other sessions. Where any credential material is exposed to the client, establish what it is and whether it is reusable.
Prerequisites — An administrative account, to test whether credentials are retrievable administratively; a second concurrent session to test invalidation.
Indicators — A password retrievable or emailed in recoverable form; password change not requiring the current password; other sessions surviving a password change; reusable credential material exposed to the client.
Coverage — WSTG-ATHN-09V2.5.3V3.3.3CWE-522CWE-256
Depth — Manual Storage strength cannot be read from outside; what is testable is the behaviour around it, which requires a deliberate sequence.
WEB-ATHN-09 Password Change and Reset Flows
Objective — Determine whether the recovery path proves the requester's identity to the same standard as the login it bypasses, and whether the artefacts it issues are constrained.
How it is tested — Initiate recovery and examine the token issued: its entropy, lifetime, whether it is single-use, and whether it is bound to the account that requested it. Attempt to use a token after expiry, twice, and against a different account. Determine whether the reset can be redirected to an attacker-controlled destination by manipulating host or email parameters in the request, and whether completing a reset invalidates existing sessions and second-factor enrolments.
Prerequisites — Two accounts with mailboxes the tester controls; the ability to intercept the request that initiates recovery; a proxy.
Indicators — A token that is guessable, long-lived, reusable or not bound to its account; a reset link constructed from a client-supplied host; sessions or second factors surviving a reset.
Coverage — WSTG-ATHN-09V2.5.6V2.5.1CWE-640CWE-620
Depth — Manual The host-manipulation and cross-account cases require constructing requests the interface never issues.
WEB-ATHN-10 Race Conditions in Authentication
Objective — Determine whether authentication and its surrounding counters behave correctly when requests arrive concurrently rather than in sequence.
How it is tested — Issue authentication attempts, second-factor submissions and recovery redemptions in parallel rather than serially, so that they reach the server before the preceding one has committed. Establish whether lockout counters, single-use tokens and enrolment operations remain correct under that condition. Repeat for operations that should be exclusive, such as consuming a one-time code or completing a reset, to determine whether the exclusivity is enforced transactionally or only by ordering.
Prerequisites — A non-production environment; a client able to issue genuinely concurrent requests; a disposable account.
Indicators — A single-use token consumed more than once; a lockout counter under-counting concurrent failures; two conflicting operations both succeeding; an enrolment completed twice.
Coverage — WSTG-ATHN-03V11.1.6CWE-367
Depth — Manual Concurrency is not part of a scanner's request model; the timing has to be arranged deliberately.
WEB-ATHN-11 Multi-Factor Authentication
Objective — Determine whether a second factor is genuinely required to reach an authenticated state, and whether it can be skipped, replayed, or removed by a principal who has only the first factor.
How it is tested — Complete the first factor and then request post-authentication routes directly, without submitting the second. Determine whether the intermediate state carries any privilege. Test whether the second-factor code is bound to the session that requested it, whether it expires, whether it is single-use, and whether it may be brute-forced within its lifetime. Establish whether enrolment, replacement or disabling of the second factor requires more than the first factor.
Prerequisites — An account with a second factor enrolled and the ability to enrol another; access to the second-factor channel; a proxy.
Indicators — Post-authentication routes reachable in the intermediate state; a code valid across sessions, reusable, or brute-forceable; the second factor removable using only the password.
Coverage — WSTG-ATHN-11V2.2.6V2.8.1CWE-287CWE-308
Depth — Manual The decisive case is what the half-authenticated state can reach, which requires stopping deliberately between the two steps.
WEB-ATHN-12 CAPTCHA Implementation
Objective — Determine whether an anti-automation control is enforced on the server for every request it is meant to protect, rather than being presented by the interface and validated loosely or not at all.
How it is tested — Submit the protected operation without the challenge parameter, with an empty value, with a previously used solution, and with a solution obtained for a different session. Determine whether the challenge is required on retry and on alternative channels, or only on the first attempt through the web form. Establish whether the challenge is generated server-side and whether its solution is ever recoverable from the response.
Prerequisites — An operation protected by the control; a proxy; the ability to replay a previously solved challenge.
Indicators — The operation succeeding without the parameter; a solution accepted more than once or across sessions; the challenge absent from an alternative channel; the solution derivable from the response.
Coverage — WSTG-ATHN-03V2.2.1CWE-804CWE-307
Depth — Manual Requires removing and replaying parameters the interface always sends correctly.
WEB-ATHN-13 Weaker Authentication in Alternative Channels
Objective — Determine whether every route into the same account enforces the same authentication strength, or whether one channel is materially weaker than the primary web login.
How it is tested — Enumerate every authentication channel the application supports — mobile clients, API endpoints, legacy interfaces, single sign-on, partner integrations and support tooling — and authenticate through each in turn. Compare lockout, password policy, second-factor requirement, session lifetime and recovery across them. Where a channel issues a session usable by the others, establish whether the weakest channel can produce a session the strongest would not have granted.
Prerequisites — Credentials usable on every channel; a client for each; a written list of channels from the operator, since the undocumented ones are the point.
Indicators — A channel omitting the second factor or the lockout policy; a longer session lifetime on one channel; a session obtained through a weak channel accepted by the strong one.
Coverage — WSTG-ATHN-10V2.2.1CWE-287CWE-1390
Depth — Manual The channels have to be enumerated before they can be compared, and the weakest is usually the one nobody listed.
What we need from you
At least two accounts, one of which may be locked out and recovered without disrupting anyone; access to the mailbox, phone number or authenticator used for recovery and second factors; a non-production environment for the lockout and brute-force cases; and a list of every channel through which the application can be authenticated, including mobile and API clients.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- WSTG-ATHN-01 — Testing for Credentials Transported over an Encrypted Channel
- V9.1.1 — Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications.
- CWE-319 — Cleartext Transmission of Sensitive Information
- CWE-522 — Insufficiently Protected Credentials
- WSTG-IDNT-04 — Testing for Account Enumeration and Guessable User Account
- CWE-204 — Observable Response Discrepancy
- CWE-203 — Observable Discrepancy
- WSTG-ATHN-03 — Testing for Weak Lock Out Mechanism
- V2.2.1 — Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account.
- CWE-307 — Improper Restriction of Excessive Authentication Attempts
- CWE-645 — Overly Restrictive Account Lockout Mechanism
- WSTG-ATHN-04 — Testing for Bypassing Authentication Schema
- WSTG-SESS-10 — Testing JSON Web Tokens
- V3.2.1 — Verify the application generates a new session token on user authentication.
- CWE-287 — Improper Authentication
- CWE-288 — Authentication Bypass Using an Alternate Path or Channel
- WSTG-ATHN-05 — Testing for Vulnerable Remember Password
- V3.3.1 — Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties.
- CWE-539 — Use of Persistent Cookies Containing Sensitive Information
- WSTG-ATHN-06 — Testing for Browser Cache Weakness
- V8.2.1 — Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers.
- V8.2.3 — Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.
- CWE-525 — Use of Web Browser Cache Containing Sensitive Information
- WSTG-ATHN-07 — Testing for Weak Password Policy
- V2.1.1 — Verify that user set passwords are at least 12 characters in length (after multiple spaces are combined).
- CWE-521 — Weak Password Requirements
- CWE-1391 — Use of Weak Credentials
- WSTG-ATHN-09 — Testing for Weak Password Change or Reset Functionalities
- V2.5.3 — Verify password credential recovery does not reveal the current password in any way.
- V3.3.3 — Verify that the application gives the option to terminate all other active sessions after a successful password change (including change via password reset/recovery), and that this is effective across the application, federated login (if present), and any relying parties.
- CWE-256 — Plaintext Storage of a Password
- V2.5.6 — Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as time-based OTP (TOTP) or other soft token, mobile push, or another offline recovery mechanism.
- V2.5.1 — Verify that a system generated initial activation or recovery secret is not sent in clear text to the user.
- CWE-640 — Weak Password Recovery Mechanism for Forgotten Password
- CWE-620 — Unverified Password Change
- V11.1.6 — Verify that the application does not suffer from "Time Of Check to Time Of Use" (TOCTOU) issues or other race conditions for sensitive operations.
- CWE-367 — Time-of-check Time-of-use (TOCTOU) Race Condition
- WSTG-ATHN-11 — Testing Multi-Factor Authentication (MFA)
- V2.2.6 — Verify replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes.
- V2.8.1 — Verify that time-based OTPs have a defined lifetime before expiring.
- CWE-308 — Use of Single-factor Authentication
- CWE-804 — Guessable CAPTCHA
- WSTG-ATHN-10 — Testing for Weaker Authentication in Alternative Channel
- CWE-1390 — Weak Authentication
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.