Loading module...
Loading module...
OWASP-07
Confirmation of the user's identity, authentication, and session management is critical.
Authentication failures occur when an attacker tricks a system into recognizing an invalid or incorrect user as legitimate.
Impact: Maintains position at #7 with 36 CWEs. Despite benefits from standardized frameworks, authentication remains a critical vulnerability area.
Uses weak or ineffective credential recovery and forgot-password processes (knowledge-based answers cannot be made safe).
Uses plain text, encrypted, or weakly hashed passwords in data stores.
Missing or ineffective multi-factor authentication, or weak fallbacks when MFA unavailable.
Use of hard-coded passwords or credentials (CWE-259, CWE-798).
Most modern web and mobile applications move state across services using JSON Web Tokens (JWTs). A JWT is a signed claim: the server signs a payload (user ID, expiration, roles) with a key, the client stores the token, and any service that holds the verification key can confirm the token is authentic without a round-trip to the auth server. JWTs are signed, not encrypted. The payload is base64url-encoded and readable by anyone who sees the token.
The signature is where authentication actually lives. The JWT header includes an alg field naming the signing algorithm, for example:
{"alg": "HS256", "typ": "JWT"} ← symmetric: HMAC-SHA256 with a shared secret
{"alg": "RS256", "typ": "JWT"} ← asymmetric: RSA signature, private key signs, public key verifies
Two classic attacks exploit careless verification:
alg: none acceptanceEarly JWT libraries accepted "alg": "none" as a valid algorithm, meaning "this token is unsigned." An attacker crafts a token with {"alg":"none"} in the header, sets sub to the target user ID, omits the signature block entirely, and sends it. A library that trusts the header as authoritative accepts it and logs the attacker in as any user. This bug shipped in multiple mainstream libraries (notable early case: jwt-simple in 2015).
The server is configured to verify with RS256 (asymmetric): the public key is, by definition, public and often exposed at a JWKS endpoint. If the verification code takes the algorithm from the token header instead of pinning it, an attacker flips the header to "alg":"HS256" (symmetric) and signs the token with the public key itself as the HMAC secret. A vulnerable library sees alg: HS256, grabs whatever key was configured for verification (the RSA public key bytes), treats those bytes as the HMAC secret, and computes a signature that matches what the attacker produced. The token passes verification.
This class of bug has been found repeatedly in the wild, including in widely-used libraries like jsonwebtoken (Node.js, CVE-2022-23529).
algorithms as "whatever is in the token header." Verify code should say explicitly: "this endpoint only accepts RS256" or "only HS256," and reject everything else including none.exp (expiration), nbf, iss (issuer), aud (audience). An unexpired, correctly-signed token for the wrong audience is still a failure.Attackers use lists of known username/password combinations and adjust passwords based on human behavior.
Attack: Changing 'Winter2025' to 'Winter2026', or 'ILoveMyDog6' to 'ILoveMyDog7' or 'ILoveMyDog5'.
Impact: More effective than traditional credential stuffing. Without defenses against automated threats, application becomes a password oracle to determine valid credentials.
Most successful authentication attacks occur due to continued use of passwords as sole authentication factor.
Problem: Password rotation and complexity requirements (once considered best practices) encourage users to reuse passwords and use weak passwords.
Solution: Stop these practices per NIST 800-63 and enforce multi-factor authentication on all important systems.
Application session timeouts aren't implemented correctly.
Attack: User uses public computer, closes browser tab instead of logging out. Another user (or attacker) uses same browser and accesses victim's authenticated session.
SSO Example: Single Sign-On session can't be closed by Single Logout (SLO). Logging out of one application doesn't log out of mail reader, document system, and chat system.
Impact: Unauthorized access to victim's account and data.
Implement MFA to prevent automated credential stuffing, brute force, and stolen credential reuse attacks.
Do not ship or deploy with any default credentials, particularly for admin users.
Align password length, complexity, and rotation policies with NIST 800-63 guidelines:
Harden registration, credential recovery, and API pathways against account enumeration attacks using same messages for all outcomes.
Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks detected.
Content adapted from OWASP Top 10:2025, licensed under CC BY-SA 4.0