OWASP Top 10 A07 Guide: Authentication Failures (2025): Stronger Sign-In and Session Handling

Most successful attacks on web applications still begin with a login that accepted someone it should not have. A07:2025 Authentication Failures is the OWASP Top 10 category for applications that confirm an invalid or incorrect user as legitimate: credential stuffing that goes unthrottled, default and breached passwords, weak recovery, missing or bypassable MFA, session identifiers that survive logout, and tokens accepted without checking who they were issued for. This guide goes deeper than the OWASP Top 10 Guide: it explains what the category contains in the 2025 edition, the requirements that close it, how service accounts and API credentials fall inside it, and how to evidence the fix to an assessor. It is written for application security engineers, identity architects and the testers who sign off releases.

Key takeaways

• The name changed, the rank did not. In the 2025 edition the category is "Authentication Failures" (previously "Identification and Authentication Failures"), still at number 7, with 36 CWEs mapped.
• Passwords alone are the root problem. OWASP states that most successful authentication attacks exploit reliance on passwords as the only factor; MFA, breached-password screening and throttling together remove most of the risk.
• Sessions are part of authentication. Session fixation (CWE-384), insufficient expiration (CWE-613) and SSO logout that does not end downstream sessions all sit in A07, not in a separate category.
• Machine credentials count. Hard-coded passwords and credentials (CWE-259, CWE-798), default credentials (CWE-1392) and tokens accepted without checking audience and scope are A07 failures, and they usually belong to non-human identities.
• Buy, do not build. OWASP recommends a well-trusted, premade system for authentication and session management; most custom login code is where these CWEs are born.

What it is and who it applies to

OWASP describes A07:2025 as the case where a system can be tricked into recognising an invalid or incorrect user as legitimate. The category keeps the number 7 position it has held since 2021, and the rename reflects that its 36 CWEs are about authentication rather than identification. OWASP's published statistics for the category are a maximum incidence rate of 15.80%, an average incidence rate of 2.92%, average coverage of 37.14%, 1,120,673 total occurrences and 7,147 CVEs mapped to its CWEs.

It applies to any application or API that decides who a caller is: customer login pages, workforce portals, admin consoles, mobile back ends, partner APIs and the internal services that accept a token from another service. The A07 risk sits with the team that owns the authentication decision. Where authentication is delegated to an identity provider, the application still owns session handling after the redirect, token validation and logout behaviour.

Two boundaries matter. Password storage with weak or reversible hashing is listed in the A07 description but OWASP points to A04:2025 Cryptographic Failures for the fix, see the OWASP Top 10 A04 Guide. Deciding what an authenticated user may do is A01:2025 Broken Access Control, see the OWASP Top 10 A01 Guide.

Structure and key requirements

The 36 mapped CWEs fall into six clusters. Grouping them this way turns a long weakness list into a set of design reviews a team can actually run.

OWASP's prevention list for the category, read alongside NIST SP 800-63B-4 (final, July 2025) and ASVS 5.0, gives these concrete requirements:

• MFA: implement and enforce MFA wherever possible. SP 800-63B-4 requires verifiers at AAL2 to offer at least one phishing-resistant option and requires phishing resistance at AAL3. See the Phishing-Resistant MFA Guide.
• Password length: SP 800-63B-4 section 3.1.1.2 sets a minimum of 15 characters where a password is the only factor and 8 where it is used only as part of MFA, and verifiers should accept at least 64 characters. ASVS 5.0 requirement V6.2.1 sets 8 as the floor and strongly recommends 15.
• No composition or rotation rules: do not impose character-mix rules or periodic changes; force a reset only on evidence of compromise. See the Password Policy Guide (NIST-aligned).
• Blocklist: screen new and changed passwords against common and breached values. OWASP suggests at least the 10,000 worst passwords plus a breached-credential corpus; ASVS V6.2.4 requires at least the top 3,000 passwords that match the policy.
• No default accounts: do not ship or deploy default credentials (ASVS V6.3.2: accounts such as root, admin or sa absent or disabled).
• Uniform responses: return the same message, status code and timing for unknown user, wrong password and locked account across login, registration and recovery, to stop account enumeration.
• Throttling: limit or progressively delay failed attempts per account without creating a denial-of-service lever, log every failure and alert on patterns. SP 800-63B-4 section 3.2.2 caps consecutive failures on one authenticator at 100.
• Session manager: use the framework's server-side session manager, issue a new high-entropy ID at login (ASVS V7.2.4), keep IDs out of URLs, and invalidate on logout, idle timeout and absolute timeout.
• Token audience and scope: check aud, iss and scopes before accepting a JWT (ASVS V9.2.3). See the JWT Security Guide.

For timeouts, SP 800-63B-4 says AAL2 sessions should be reauthenticated at least every 24 hours with an inactivity timeout of 1 hour or less, and AAL3 sessions must be reauthenticated within 12 hours with an inactivity timeout of 15 minutes or less. The OWASP Session Management Cheat Sheet recommends session IDs with at least 64 bits of entropy from a CSPRNG and cookies set as __Host- prefixed with Secure, HttpOnly, SameSite=Strict or Lax, and Path=/. See the Token and Session Security Guide.

Identity and NHI requirements

A07 is usually read as a customer login problem, but several of its CWEs describe machine credentials. Hard-coded credentials, default passwords on appliances and services trusting tokens without checking their audience are all non-human identity failures. The OWASP NHI Top 10 NHI4 Insecure Authentication Guide covers the NHI side in depth; the points below are where it meets A07.

• Replace static secrets: where a platform supports it, use workload identity federation or managed identities instead of long-lived keys. See the Workload Identity Federation Guide.
• Treat service accounts as accounts: MFA cannot apply to a workload, so the compensating controls are short lifetimes, source restrictions and monitoring for interactive use. The Snowflake breach shows the cost: infostealer-harvested passwords, some dating back to 2020, opened customer instances that had no MFA, no rotation and no network allow lists.
• Protect the authentication path for agents: AI agents calling APIs on a user's behalf need delegated, scoped and audience-bound tokens, not a shared key. See the NHI Authentication Guide.

Implementation steps

1. Inventory every authentication path. List login pages, API authentication, recovery, MFA enrolment, remember-me, mobile, legacy protocols and service-to-service calls. Alternate paths (CWE-288) are where bypasses hide, so include admin and support routes.
2. Centralise on a proven component. Move custom login code to the framework or identity provider. Record any remaining custom code as a risk with an owner.
3. Turn on MFA in rings. Start with administrators and privileged users, then all workforce users, then customers with stored value or personal data. Offer passkeys or other phishing-resistant options first, and keep SMS only as a fallback with a retirement date. See the Passwordless and Passkeys Guide.
4. Add breached-password screening and length rules. Deploy in report-only mode for two weeks to measure how many existing passwords would fail, then enforce at next change.
5. Deploy throttling and bot defence. Per-account progressive delay plus per-source rate limits at the edge; measure the false positive rate before enforcing. See the Password Spraying and Credential Stuffing Defence Guide.
6. Harden sessions. Rotate the ID at login and privilege change, set cookie attributes, set idle and absolute timeouts server side, and make logout revoke the server session and refresh tokens. Test back-channel or front-channel logout for SSO applications.
7. Fix recovery. Remove knowledge-based questions, require the current authenticator for sensitive changes (CWE-620), and treat recovery as at least as strong as login. See the MFA Fatigue and Bypass Guide.
8. Remove machine credentials from code. Run secret scanning across repositories and images, move findings to a vault or federation, rotate anything that was exposed and block new commits with secrets.
9. Roll back safely. Ship each control behind a feature flag. If MFA enrolment or lockout causes support volume to spike, revert the flag for the affected ring, not the whole control, and fix enrolment before retrying.

Small versus large organisations: a small team should delegate login to a reputable identity provider and spend its effort on session handling and token validation inside the application. A large organisation with many applications gets more from a shared authentication service with central policy, bot defence at the edge and one set of logs, but must test that every application actually validates tokens rather than trusting the gateway.

Evidence and assessment

An assessor or auditor will want to see that the controls exist and that they work. The OWASP Web Security Testing Guide authentication chapter (4.4) covers credentials over encrypted channels, default credentials, weak lockout, bypassing the authentication schema, remember-password, browser cache, weak password policy, security questions, password change and reset, and weaker authentication in alternative channels; its session management chapter covers fixation, cookies and logout.

Detection and metrics. Log every authentication success and failure with account, source, user agent and method; alert on many accounts failing from one source (spraying), one account failing from many sources (stuffing), MFA prompts denied in succession and service accounts logging in interactively. ATT&CK techniques to tune detections against include T1110.003 Password Spraying, T1110.004 Credential Stuffing, T1621 Multi-Factor Authentication Request Generation, T1539 Steal Web Session Cookie and T1078 Valid Accounts. Useful KPIs:

• MFA coverage by population (target 100% of administrators, then workforce).
• Percentage of logins using phishing-resistant authenticators.
• Credential stuffing attempts blocked versus accounts taken over per month.
• Hard-coded secrets found per scan and median time to rotate.
• Applications passing the logout and token-audience tests.

Mapping to other frameworks

Common pitfalls

• MFA on the front door only. The main login has MFA, but an API, legacy protocol or support route accepts a password alone. The Change Healthcare breach began with a remote access login that did not require MFA.
• No defence against credential stuffing. Valid passwords from other breaches are tried at volume and the application acts as a password oracle. In the 23andMe breach, stuffing opened more than 18,000 accounts, and a sharing feature exposed data on almost 7 million people; regulators cited the lack of mandatory MFA.
• Lockout that becomes denial of service. Hard lockout after five failures lets an attacker lock out every user they can enumerate. Use progressive delay and risk signals instead.
• Logout that only clears the browser. The cookie is deleted but the server session and refresh token remain valid, so a stolen cookie keeps working. See the Session Hijacking and Cookie Theft Guide.
• Default and hard-coded credentials in shipped products. The McHire default password flaw shows the pattern: a dormant vendor test administrator account with 123456 as both username and password, no MFA and a sign-in link that bypassed SSO, gave researchers a foothold on a live hiring platform.
• Trusting any valid signature. A service accepts a JWT because the IdP signed it, without checking that it was issued for this service, so a token for a low-value application unlocks a high-value one.

Practitioner checklist

• Inventory every authentication path, including APIs, recovery, legacy protocols and service-to-service calls.
• Enforce MFA on all paths for administrators and workforce users, with phishing-resistant options offered first.
• Apply SP 800-63B-4 password rules: length 15 for single factor, at least 64 accepted, no composition or forced rotation, breached-password screening.
• Remove default accounts and fail builds that contain default or hard-coded credentials.
• Throttle per account with progressive delay, return uniform errors and alert on spraying and stuffing patterns.
• Rotate session IDs at login, set __Host-, Secure, HttpOnly and SameSite, and enforce idle and absolute timeouts on the server.
• Make logout revoke server sessions and refresh tokens, and test SSO logout across applications.
• Validate aud, iss, expiry and scope on every token, for users and workloads.
• Replace static machine credentials with federated or vault-issued short-lived credentials.
• Track MFA coverage, account takeover rate and secret rotation time monthly.

Standards and references

• OWASP: A07:2025 Authentication Failures
• NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
• OWASP: Application Security Verification Standard 5.0
• OWASP: Authentication Cheat Sheet
• OWASP: Session Management Cheat Sheet
• OWASP: Web Security Testing Guide, Authentication Testing
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Brute Force

Related NHI Mgmt Group resources: OWASP Top 10 Guide · OWASP Top 10 A08 Guide · Authentication Guide · MFA Guide · OWASP ASVS Guide