Objective
Verify that the application correctly establishes, maintains and terminates user identity and authentication state, and that authentication mechanisms resist unauthorized access through predictable, weak or improperly protected paths.
Authentication failures occur when an application accepts an invalid or incorrect identity as legitimate, or when authentication mechanisms can be bypassed or weakened through predictable credentials, automated attacks, recovery workflows, MFA weaknesses or session-management errors.
OWASP Top 10:2025 places Authentication Failures at A07:2025. The category includes 36 mapped CWEs covering authentication, credentials, session fixation, password recovery, excessive authentication attempts and related weaknesses. :contentReference[oaicite:0]{index=0}
Scope
Review all mechanisms responsible for establishing or maintaining authenticated identity, including:
Prerequisites
| Authorization | Confirm authorization to test authentication, account and session functionality. |
|---|---|
| Test accounts | Prepare authorized accounts representing relevant roles and authentication states. |
| Recovery access | Where permitted, prepare access to the controlled email, phone or recovery mechanism associated with test accounts. |
| Application map | Identify authentication endpoints, account-management functions and authentication-related APIs. |
| Test environment | Prefer a controlled environment for repeated authentication testing. |
Methodology
Authentication testing should evaluate the complete identity lifecycle rather than testing the login form in isolation.
| Review stage | Primary question |
|---|---|
| Identity | How does the application determine which account is being authenticated? |
| Credentials | Are credentials sufficiently strong, protected and validated? |
| Authentication | Can an attacker bypass or weaken the authentication decision? |
| Session | Is authentication state securely created, maintained and invalidated? |
| Recovery | Does account recovery provide an equivalent security level? |
| Automation | Can automated attacks be performed without appropriate resistance or detection? |
Test procedure
Credential security
Verify that password requirements prevent obviously weak credentials without imposing unnecessary restrictions that encourage reuse.
Verify that account creation and password changes can reject known compromised credentials where required by the security policy.
Verify that deployed applications and administrative interfaces do not use default or well-known credentials.
Verify that passwords are not stored in plaintext, reversible encryption or weak hashing schemes.
Verify that credentials are transmitted only through appropriately protected channels.
Review application code and deployment configuration for hard-coded authentication credentials.
Password policy should be based on current, evidence-based guidance. OWASP's 2025 guidance specifically recommends breached-credential checks and alignment with modern NIST password guidance rather than blindly enforcing arbitrary periodic password rotation. :contentReference[oaicite:1]{index=1}
Brute force and credential attack resistance
Authentication endpoints should resist automated attempts such as brute force, credential stuffing and password spraying without introducing an unnecessary denial-of-service condition for legitimate users.
Do not perform high-volume credential attacks against production systems or accounts that you do not own. Use designated test accounts, controlled request rates and an agreed testing window.
Multi-factor authentication
Where MFA is required, the assessment should verify that authentication cannot be completed by bypassing, downgrading or incorrectly implementing the additional factor.
A system can advertise MFA while still having an authentication weakness if an alternate route, recovery mechanism or incomplete implementation allows the additional factor to be bypassed.
Password reset and account recovery
Account recovery must preserve the security objective of authentication. A strong login mechanism does not protect an account if the recovery process can be used to obtain access with substantially weaker proof of identity.
| Review area | Verification focus |
|---|---|
| Account enumeration | Registration and recovery responses should avoid unnecessarily revealing whether an account exists. |
| Reset token | Tokens should be unpredictable, scoped, single-use and appropriately time-limited. |
| Token exposure | Reset secrets should not be unnecessarily exposed through URLs, logs, referrers or client-side storage. |
| Identity verification | Recovery should provide appropriate proof that the requester controls the account. |
| Existing sessions | Sensitive recovery operations should appropriately handle existing sessions and authentication tokens. |
| Password change | Changing credentials should not silently weaken authentication state. |
Session lifecycle
A new high-entropy session identifier should be established after successful authentication.
The application should prevent session fixation by changing the session identifier when authentication state changes.
Session cookies should use appropriate security attributes such as Secure, HttpOnly and an appropriate SameSite policy.
Sessions should expire according to defined idle and absolute timeout requirements.
Logout should invalidate the relevant server-side session or authentication state.
Authentication tokens should be accepted only for their intended issuer, audience, scope and purpose.
Set-Cookie:
session=RANDOM_HIGH_ENTROPY_VALUE;
Secure;
HttpOnly;
SameSite=Lax;Controlled reproduction
Baseline authentication
POST /login HTTP/1.1
Host: application.example
Content-Type: application/x-www-form-urlencoded
username=test-user
password=<authorized-test-password>Controlled negative test
POST /login HTTP/1.1
Host: application.example
Content-Type: application/x-www-form-urlencoded
username=test-user
password=<incorrect-test-password>Compare the successful and unsuccessful authentication paths. The review should determine whether invalid credentials are rejected consistently and whether authentication state is established only after successful verification.
Session rotation check
Authentication testing must use authorized accounts and controlled credentials. Never attempt to validate a finding by accessing another person's account.
Assessment
| Condition | Assessment consideration |
|---|---|
| Strong authentication | Invalid authentication attempts are rejected and the complete identity lifecycle is appropriately protected. |
| Weak credentials | Weak, default or compromised credentials can be used when they should be rejected. |
| Authentication bypass | A user can reach an authenticated state without satisfying the required authentication conditions. |
| Session weakness | Authentication state can be fixed, reused or retained beyond its intended lifetime. |
| Recovery weakness | Account recovery provides insufficient identity assurance. |
| Automation weakness | Automated credential attacks can be performed without effective controls. |
Failure criteria
The application permits repeated authentication attempts against a valid account without effective rate limiting or equivalent automated-attack resistance. Controlled testing demonstrates that repeated attempts can continue without meaningful restriction, increasing exposure to brute-force, credential-stuffing or password-spraying attacks.
Remediation
Authentication controls should preferably use mature, well-tested frameworks or identity platforms rather than implementing authentication primitives from scratch.
- Use a well-maintained authentication and session management framework where practical.
- Disable all default credentials before deployment.
- Reject weak and known-compromised passwords according to the application's security requirements.
- Implement appropriate resistance against brute-force, credential-stuffing and password-spraying attacks.
- Use MFA for systems and operations requiring stronger authentication assurance.
- Ensure MFA fallback mechanisms do not undermine the primary MFA control.
- Generate new high-entropy session identifiers after authentication-state changes.
- Store session identifiers using appropriately secured cookies rather than insecure client-controlled locations.
- Invalidate sessions and relevant authentication tokens on logout, expiration and security-sensitive events.
- Design password recovery with appropriate identity verification and single-use recovery mechanisms.
- Prevent account enumeration where it would expose sensitive authentication information.
- Validate authentication-token issuer, audience and scope where applicable.
Combining custom cookies, custom password logic, homemade token formats and application-specific authentication checks increases the probability of subtle authentication failures. OWASP explicitly recommends using a trusted, hardened system for authentication, identity and session management where possible. :contentReference[oaicite:2]{index=2}
Post-remediation verification
Authentication controls correctly reject the tested unauthorized condition and preserve the intended authentication lifecycle.
The original authentication weakness or an equivalent bypass remains reproducible.
The authentication control could not be adequately evaluated with the available access or evidence.
Evidence requirements
Redact passwords, session cookies, reset tokens, MFA secrets, recovery codes, API credentials and other authentication material before storing or publishing assessment evidence.
Classification
| WebOTG procedure | WebOTG-AF-001 |
|---|---|
| OWASP category | A07:2025 — Authentication Failures |
| Procedure type | Authentication, credential and session security assessment |
| Assessment result | PASS / FAIL / NOT TESTED |
| Finding severity | Determine according to the authentication assurance affected, privileges obtainable, assets exposed, exploitability and resulting impact. |
WebOTG-AF-001 is a WebOTG-defined verification procedure. The identifier is not an OWASP-defined test identifier.
References
| Source | Relevance |
|---|---|
| OWASP Top 10:2025 — A07 | Primary category definition for Authentication Failures. |
| OWASP Web Security Testing Guide | Authentication, session-management and application security testing guidance. |
| OWASP Application Security Verification Standard | Verification requirements relevant to authentication and session security. |
| NIST SP 800-63B | Modern guidance concerning authentication and memorized secrets. |
| CWE | Common weakness classifications for authentication and session-related vulnerabilities. |
WebOTG should maintain authoritative source references, document versions and review dates through its content management system so that the procedure can be updated independently from application code.