Category: Vulnerability Management

Broken Authentication

Also known as: Authentication Vulnerability, Broken Authentication and Session Management

Simply put

Broken authentication refers to security weaknesses in a web application's login process or session management that allow attackers to impersonate legitimate users. These flaws can enable unauthorized access to user accounts by compromising passwords, session tokens, or other credentials. It is considered an umbrella term covering several distinct vulnerability types related to how applications verify and maintain user identity.

Formal definition

Broken authentication is a class of web application vulnerabilities arising from incorrect implementation of authentication mechanisms and session management controls. Affected implementations may exhibit logic flaws or coding errors that allow authentication to be bypassed entirely, or may inadequately protect credentials, session tokens, or API keys in ways that permit an attacker to assume another user's identity. The category encompasses weaknesses such as insecure credential storage, predictable or poorly invalidated session tokens, and flawed multi-factor or login flow logic. Because authentication correctness depends heavily on runtime behavior and application-specific logic, many instances of broken authentication are not detectable through static analysis alone and typically require dynamic testing or runtime context to identify.

Why it matters

Authentication is the foundation of access control in any application. When authentication mechanisms are broken, an attacker does not need to exploit complex vulnerabilities elsewhere in the system because they can simply impersonate a legitimate user and inherit all of that user's privileges. This makes broken authentication one of the highest-impact vulnerability classes, as it can lead directly to account takeover, unauthorized access to sensitive data, privilege escalation, and downstream compromise of connected systems.

The vulnerability class is particularly dangerous because it is broad. It covers everything from weak password policies and insecure credential storage to predictable session tokens and flawed multi-factor authentication logic. A single flaw in any part of the login flow or session lifecycle can be sufficient for an attacker to gain unauthorized access. Because these weaknesses span the full authentication lifecycle, they are difficult to address through a single control and typically require coordinated improvements across application design, implementation, and configuration.

Broken authentication has been recognized as a critical risk category by OWASP for multiple consecutive years in its Top 10 list, reflecting the persistent frequency and severity of these vulnerabilities across web applications. The category appears consistently because correct authentication implementation requires careful attention to runtime behavior and application-specific logic, not just adherence to coding patterns, making it easy for subtle flaws to go undetected through standard code review alone.

Who it's relevant to

Application Developers

Developers bear primary responsibility for implementing authentication and session management correctly. They need to understand which specific coding patterns introduce broken authentication risks, such as insecure credential storage, insufficient token randomness, or missing session invalidation logic, and apply secure-by-default libraries and frameworks rather than building authentication mechanisms from scratch. Awareness of how subtle logic errors in login flows can be exploited is essential during both initial development and code review.

Security Engineers and Penetration Testers

Security practitioners testing web applications must understand that broken authentication vulnerabilities typically require dynamic testing or runtime context to surface, and that static analysis alone will often produce false negatives for this class. Effective assessment involves active techniques such as manipulating session tokens, testing for credential stuffing exposure, probing multi-factor authentication flows, and verifying that sessions are properly invalidated. Scope boundaries should be clearly defined, as some authentication logic may only be observable in production-like environments.

Product Managers and Application Owners

Product managers and application owners are responsible for ensuring that authentication requirements are treated as first-class design concerns rather than implementation details. Because broken authentication can lead directly to account takeover and unauthorized access to user data, the business risk is substantial. They should understand that this vulnerability class spans design, implementation, and configuration, and that addressing it typically requires coordinated investment across multiple development and security activities rather than a single fix.

Security Architects

Architects need to evaluate authentication mechanisms at the design level, ensuring that the overall system does not rely on authentication patterns that are inherently difficult to implement securely. This includes assessing whether session management is handled by well-maintained libraries, whether credential handling pipelines minimize exposure, and whether authentication flows are resilient to logic manipulation. Architectural decisions about token lifecycle, multi-factor authentication integration, and API key management all influence the attack surface for broken authentication.

DevSecOps and AppSec Program Teams

Teams responsible for application security programs need to account for the detection limitations of automated tooling when dealing with broken authentication. Because many instances require dynamic or runtime analysis to identify, programs that rely solely on static analysis in CI/CD pipelines may have significant gaps in coverage for this vulnerability class. Incorporating dynamic application security testing, authenticated scanning, and periodic manual review of authentication logic into the security testing pipeline is typically necessary to achieve meaningful detection coverage.

Inside Broken Authentication

Credential-Based Attacks

Exploitation techniques such as brute force, credential stuffing, and password spraying that target weak or reused credentials to gain unauthorized access to authenticated sessions.

Session Management Weaknesses

Flaws in how session tokens are generated, transmitted, stored, or invalidated, including predictable token values, tokens exposed in URLs, and failure to invalidate tokens after logout or timeout.

Multi-Factor Authentication (MFA) Absence or Bypass

The lack of MFA, or the presence of implementation flaws that allow MFA to be circumvented, leaving authentication reliant on a single factor that may be compromised.

Insecure Password Policies

Permitting weak, short, or commonly used passwords without enforcement of complexity or length requirements, making accounts more susceptible to guessing and brute force attacks.

Default or Hardcoded Credentials

Shipping applications or systems with unchanged default usernames and passwords, or embedding credentials directly in source code, which attackers can trivially exploit.

Insecure Credential Recovery Flows

Password reset and account recovery mechanisms that rely on weak security questions, predictable tokens, or improperly validated out-of-band channels, enabling account takeover without knowing the original password.

Token Exposure and Transmission Risks

Scenarios in which authentication tokens or session identifiers are transmitted over unencrypted channels or included in logs, referrer headers, or browser history, making them accessible to unauthorized parties.

Common questions

Answers to the questions practitioners most commonly ask about Broken Authentication.

Does using HTTPS automatically protect my application from broken authentication vulnerabilities?

No. HTTPS encrypts data in transit, which prevents credential interception on the network, but it does not protect against weak passwords, credential stuffing, session fixation, insecure session token storage, or missing account lockout controls. Broken authentication vulnerabilities typically exist in application logic and session management, which operate above the transport layer. HTTPS is a necessary baseline but does not substitute for properly implemented authentication mechanisms.

If my application uses OAuth or a third-party identity provider, am I protected from broken authentication?

Not necessarily. Delegating authentication to a third-party provider reduces certain risks, such as password storage and credential hashing, but broken authentication can still occur in the portions of the authentication flow your application controls. Common residual risks include improper validation of tokens or assertions received from the provider, insecure session management after the OAuth handshake completes, missing state parameter validation that exposes users to CSRF during the authorization flow, and overly broad token scopes. The integration points between your application and the identity provider require careful implementation.

How should I implement account lockout without enabling denial-of-service attacks against legitimate users?

A common approach is to use progressive delays or CAPTCHA challenges after a defined number of failed attempts rather than hard lockouts, which can be abused to lock out legitimate users. For hard lockouts, provide a self-service unlock path via a verified secondary channel such as email or SMS rather than requiring administrator intervention. Lockout thresholds should be high enough to tolerate legitimate typos, typically five to ten attempts, while still limiting automated credential stuffing. Rate limiting by IP address, in addition to per-account controls, adds a complementary layer of protection.

What session management practices are necessary to prevent session-based broken authentication?

Sessions should use cryptographically random, sufficiently long tokens generated by the server. Tokens must be rotated upon privilege escalation, including at login and when a user's role changes. Sessions should have defined idle and absolute expiration times appropriate to the sensitivity of the application. Tokens should be transmitted only over HTTPS and stored in cookies configured with the Secure, HttpOnly, and SameSite attributes. The server must invalidate the session token on logout, not just clear it client-side. Session fixation must be prevented by issuing a new token after authentication completes.

How do I evaluate whether multi-factor authentication is implemented correctly rather than just present?

Verify that MFA is enforced at the server side and cannot be bypassed by manipulating client requests, skipping workflow steps, or exploiting race conditions in the authentication flow. Confirm that the second factor is validated before any authenticated session token is issued. Check that recovery and fallback paths, such as backup codes or account recovery flows, are equally protected and do not allow MFA bypass. Test whether MFA is enforced consistently across all access paths including API endpoints, not only the primary login form. Also verify that MFA factors are bound to the specific account and cannot be reused across sessions.

Which broken authentication weaknesses are detectable through static analysis versus those that require runtime testing?

Static analysis can identify issues in code that are visible at the source level, such as hardcoded credentials, use of weak or deprecated cryptographic functions for password hashing, missing token expiration settings in configuration, and certain patterns of insecure session token generation. Runtime testing is required to detect behavioral issues that depend on execution context, including the effectiveness of rate limiting and lockout enforcement, actual token randomness and entropy, token invalidation on logout, session fixation behavior, and whether MFA can be bypassed through alternative request flows. Comprehensive coverage of broken authentication typically requires both static analysis and authenticated dynamic testing.

Common misconceptions

Broken Authentication only refers to weak passwords.

Broken Authentication encompasses a broad class of weaknesses, including session management flaws, missing or bypassable MFA, insecure credential recovery, exposed tokens, and default credentials. Weak passwords are one contributing factor, not the entirety of the category.

Implementing HTTPS fully protects against broken authentication vulnerabilities.

HTTPS protects credentials and tokens in transit but does not address weaknesses such as insecure session token generation, failure to invalidate sessions after logout, credential stuffing using valid stolen credentials, or flawed password reset flows. Transport encryption is a necessary but insufficient control.

Static analysis tools can reliably detect all broken authentication issues in code.

Static analysis can identify certain patterns, such as hardcoded credentials or missing token invalidation calls, but many broken authentication weaknesses require runtime or deployment context to detect. Issues such as session fixation behavior, token entropy adequacy, and MFA bypass conditions typically cannot be confirmed without dynamic testing or code review combined with configuration analysis.

Best practices

Enforce MFA for all user accounts, particularly for privileged roles and administrative interfaces, and validate that MFA implementation cannot be bypassed through alternative authentication flows or API endpoints.

Implement rate limiting, account lockout, and anomaly detection on authentication endpoints to mitigate brute force, credential stuffing, and password spraying attacks.

Generate session tokens using cryptographically secure random number generators with sufficient entropy, transmit them only over encrypted channels, and invalidate them immediately upon logout, password change, or session timeout.

Audit and remediate credential recovery mechanisms to ensure password reset tokens are time-limited, single-use, unpredictable, and delivered through properly validated out-of-band channels rather than security questions.

Establish and enforce a strong password policy that rejects commonly used passwords by checking against known-breached password lists, and prevent default or hardcoded credentials from reaching production systems.

Conduct regular dynamic testing and manual code review of authentication and session management logic, as static analysis alone is typically insufficient to uncover runtime session behavior, token exposure in logs, or context-dependent MFA bypass conditions.