A07:2025 - Authentication Failures

Authentication Failures holds position seven in the OWASP Top 10 for 2025, renamed from "Identification and Authentication Failures" in the 2021 edition. This category originally sat at the number two spot in the 2017 edition but has dropped steadily thanks to the increased adoption of standardized authentication frameworks and multi-factor authentication. Despite this progress, flawed authentication logic remains a significant risk when developers implement custom auth code or misconfigure existing solutions.

Overview

Authentication is the process of verifying that a user, service, or system is who it claims to be. When authentication mechanisms are weak, missing, or improperly implemented, attackers can compromise passwords, session tokens, or keys to assume other users' identities. The drop from position two in 2017 to position seven in 2025 reflects genuine industry improvement driven by mature auth libraries and OAuth/OIDC adoption.

However, Radar's analysis consistently finds that custom authentication code, especially in internal tools, legacy systems, and microservice-to-microservice communication, still harbors critical weaknesses that standard frameworks would prevent. The most frequently detected issues are hardcoded credentials in source code and weak password validation logic that accepts trivially guessable passwords.

What Radar Detects

• Hardcoded credentials.**Usernames, passwords, API keys, and tokens embedded directly in source code, configuration files, or environment setup scripts rather than being stored in a secrets manager or vault.

• Weak password validation.**Authentication flows that accept passwords without enforcing minimum length, complexity requirements, or checks against lists of commonly breached passwords, leaving accounts vulnerable to dictionary attacks.

• Session fixation.**Login flows that do not regenerate the session identifier after successful authentication, allowing an attacker who set or knows the pre-authentication session ID to hijack the authenticated session.

• Missing brute-force protection.**Login endpoints that lack rate limiting, progressive delays, account lockout, or CAPTCHA mechanisms, enabling automated credential stuffing and brute-force attacks at scale.

• Insecure password storage.**Passwords stored using reversible encryption, weak hashing algorithms (MD5, SHA-1 without salting), or in plaintext, rather than using adaptive hashing functions designed for password storage (bcrypt, scrypt, Argon2).

• Credential exposure in URLs.**Tokens, session IDs, or authentication parameters passed as URL query string parameters, where they are recorded in server access logs, browser history, referrer headers, and proxy logs.

• Missing session expiration.**Sessions that remain valid indefinitely or for excessively long periods without requiring re-authentication, increasing the window for session hijacking and token theft.

• Insecure "remember me" implementations.**Persistent login tokens stored in cookies without adequate protection (missing Secure, HttpOnly, or SameSite flags), or tokens that are predictable or not bound to the original user context.

Related CWEs

CWE-798 (Use of Hard-coded Credentials), CWE-287 (Improper Authentication), CWE-384 (Session Fixation).

See the CWE Reference for details.

Prevention

• Implement multi-factor authentication for all user-facing login flows to mitigate credential theft and brute-force attacks.
• Eliminate all default and hardcoded credentials from source code, configuration, and deployment scripts. Use a dedicated secrets manager instead.
• Validate passwords against a list of at least the top 10,000 most common passwords in addition to enforcing minimum length and complexity requirements.
• Use proven, well-maintained authentication frameworks and libraries rather than implementing custom authentication logic.
• Regenerate the session identifier immediately after successful authentication to prevent session fixation attacks.
• Apply rate limiting, progressive delays, and account lockout policies on all login and password recovery endpoints to block automated attacks.
• Never pass tokens, session IDs, or credentials in URL query strings. Use HTTP headers or POST request bodies instead.
• Enforce session timeouts appropriate to the application's risk level, requiring re-authentication after periods of inactivity.
• Set Secure, HttpOnly, and SameSite attributes on all authentication-related cookies.

Next Steps