Background
Authentication Failures maintains its position at #7 with a slight name change to more accurately reflect the 36 CWEs in this category. Despite benefits from standardized frameworks, this category has kept its #7 rank from 2021. Notable CWEs included are CWE-259 Use of Hard-coded Password, CWE-297: Improper Validation of Certificate with Host Mismatch, CWE-287: Improper Authentication, CWE-384: Session Fixation, and CWE-798 Use of Hard-coded Credentials.
Score table
| CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Max Coverage | Avg Coverage | Avg Weighted Exploit | Avg Weighted Impact | Total Occurrences | Total CVEs |
| 36 | 15.80% | 2.92% | 100.00% | 37.14% | 7.69 | 4.44 | 1,120,673 | 7,147 |
Description
When an attacker is able to trick a system into recognizing an invalid or incorrect user as legitimate, this vulnerability is present. There may be authentication weaknesses if the application:
- Permits automated attacks such as credential stuffing, where the attacker has a breached list of valid usernames and passwords. More recently this type of attack has been expanded to include hybrid password attacks credential stuffing (also known as password spray attacks), where the attacker uses variations or increments of spilled credentials to gain access, for instance trying Password1!, Password2!, Password3! and so on.
- Permits brute force or other automated, scripted attacks that are not quickly blocked.
- Permits default, weak, or well-known passwords, such as "Password1" or "admin" username with an "admin" password.
- Allows users to create new accounts with already known-breached credentials.
- Allows use of weak or ineffective credential recovery and forgot-password processes, such as "knowledge-based answers," which cannot be made safe.
- Uses plain text, encrypted, or weakly hashed passwords data stores (see A04:2025-Cryptographic Failures).
- Has missing or ineffective multi-factor authentication.
- Allows use of weak or ineffective fallbacks if multi-factor authentication is not available.
- Exposes session identifier in the URL, a hidden field, or another insecure location that is accessible to the client.
- Reuses the same session identifier after successful login.
- Does not correctly invalidate user sessions or authentication tokens (mainly single sign-on (SSO) tokens) during logout or a period of inactivity.
- Does not correctly assert the scope and intended audience of the provided credentials.
How to prevent
- Where possible, implement and enforce use of multi-factor authentication to prevent automated credential stuffing, brute force, and stolen credential reuse attacks.
- Where possible, encourage and enable the use of password managers, to help users make better choices.
- Do not ship or deploy with any default credentials, particularly for admin users.
- Implement weak password checks, such as testing new or changed passwords against the top 10,000 worst passwords list.
- During new account creation and password changes validate against lists of known breached credentials (eg: using haveibeenpwned.com).
- Align password length, complexity, and rotation policies with National Institute of Standards and Technology (NIST) 800-63b's guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence-based password policies.
- Do not force human beings to rotate passwords unless you suspect breach. If you suspect breach, force password resets immediately.
- Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes (“Invalid username or password.”).
- Limit or increasingly delay failed login attempts but be careful not to create a denial of service scenario. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected or suspected.
- Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session identifiers should not be in the URL, be securely stored in a secure cookie, and invalidated after logout, idle, and absolute timeouts.
- Ideally, use a premade, well-trusted system to handle authentication, identity, and session management. Transfer this risk whenever possible by buying and utilizing a hardened and well tested system.
- Verify the intended use of provided credentials, e.g. for JWTs validate
aud,issclaims and scopes
Example attack scenarios
Scenario #1: Credential stuffing, the use of lists of known username and password combinations, is now a very common attack. More recently attackers have been found to ‘increment’ or otherwise adjust passwords, based on common human behavior. For instance, changing ‘Winter2025’ to ‘Winter2026’, or ‘ILoveMyDog6’ to ‘ILoveMyDog7’ or ‘ILoveMyDog5’. This adjusting of password attempts is called a hybrid credential stuffing attack or a password spray attack, and they can be even more effective than the traditional version. If an application does not implement defences against automated threats (brute force, scripts, or bots) or credential stuffing, the application can be used as a password oracle to determine if the credentials are valid and gain unauthorized access.
Scenario #2: Most successful authentication attacks occur due to the continued use of passwords as the sole authentication factor. Once considered best practices, password rotation and complexity requirements encourage users to both reuse passwords and use weak passwords. Organizations are recommended to stop these practices per NIST 800-63 and to enforce use of multi-factor authentication on all important systems.
Scenario #3: Application session timeouts aren't implemented correctly. A user uses a public computer to access an application and instead of selecting "logout," the user simply closes the browser tab and walks away. Another Example for this is, if a Single Sign on (SSO) session can not be closed by a Single Logout (SLO). That is, a single login logs you into, for example, your mail reader, your document system, and your chat system. But logging out happens only to the current system. If an attacker uses the same browser after the victim thinks they have successfully logged out, but with the user still authenticated to some of the applications, then can access the victim's account. The same issue can happen in offices and enterprises when a sensitive application has not been properly exited and a colleague has (temporary) access to the unlocked computer.
References
List of Mapped CWEs
- CWE-258 Empty Password in Configuration File
- CWE-259 Use of Hard-coded Password
- CWE-287 Improper Authentication
- CWE-288 Authentication Bypass Using an Alternate Path or Channel
- CWE-289 Authentication Bypass by Alternate Name
- CWE-290 Authentication Bypass by Spoofing
- CWE-291 Reliance on IP Address for Authentication
- CWE-293 Using Referer Field for Authentication
- CWE-294 Authentication Bypass by Capture-replay
- CWE-295 Improper Certificate Validation
- CWE-297 Improper Validation of Certificate with Host Mismatch
- CWE-298 Improper Validation of Certificate with Host Mismatch
- CWE-299 Improper Validation of Certificate with Host Mismatch
- CWE-300 Channel Accessible by Non-Endpoint
- CWE-302 Authentication Bypass by Assumed-Immutable Data
- CWE-303 Incorrect Implementation of Authentication Algorithm
- CWE-304 Missing Critical Step in Authentication
- CWE-305 Authentication Bypass by Primary Weakness
- CWE-306 Missing Authentication for Critical Function
- CWE-307 Improper Restriction of Excessive Authentication Attempts
- CWE-308 Use of Single-factor Authentication
- CWE-309 Use of Password System for Primary Authentication
- CWE-346 Origin Validation Error
- CWE-350 Reliance on Reverse DNS Resolution for a Security-Critical Action
- CWE-384 Session Fixation
- CWE-521 Weak Password Requirements
- CWE-613 Insufficient Session Expiration
- CWE-620 Unverified Password Change
- CWE-640 Weak Password Recovery Mechanism for Forgotten Password
- CWE-798 Use of Hard-coded Credentials
- CWE-940 Improper Verification of Source of a Communication Channel
- CWE-941 Incorrectly Specified Destination in a Communication Channel
- CWE-1390 Weak Authentication
- CWE-1391 Use of Weak Credentials
- CWE-1392 Use of Default Credentials
- CWE-1393 Use of Default Password
- OWASP -
EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.
- OWASP Application Security Verification Standard (ASVS) 5.0.0, May 2025, from OWASP/ASVS: © 2008-2025 The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: divided into sections and converted into the GRCA format, the wording unchanged. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Mobile Application Security Verification Standard (MASVS) v2.1.0, January 2024, from OWASP/masvs: © The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: converted into the GRCA format, the wording unchanged. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Mobile Application Security Weakness Enumeration (MASWE) v1.0.0, August 2026, from OWASP/maswe: © The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: converted into the GRCA format, the wording unchanged, linked to the MASVS controls they map to. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Mobile Application Security Testing Guide (MASTG) v2.0.0, June 2026, from OWASP/mastg: © The OWASP Foundation, licensed under CC BY-SA 4.0. The tests and best practices only, without code samples, images, tools or apps. Changes: converted into the GRCA format, the wording unchanged; references to other pages of the MASTG as links to mas.owasp.org; the weakness of each test in the numbering of MASWE v1 and linked to it. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Software Assurance Maturity Model (SAMM) v2.2.0, July 2026, from owaspsamm/core: © The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: converted into the GRCA format, the wording unchanged; short codes (G-SM-1-A) built from the model, the assessment questions as assessment procedures of their activities. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Top 10:2025, from OWASP/Top10: © 2003-2025 The OWASP® Foundation, Inc., licensed under CC BY-SA 4.0. The ten categories, without the icons. Changes: converted into the GRCA format, the wording unchanged. These adaptations are shared under CC BY-SA 4.0 as well. The names of the mapped CWEs (Common Weakness Enumeration): © 2006–2026 The MITRE Corporation. License: The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. See the CWE Terms of Use. CWE™ is a trademark of The MITRE Corporation.
DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.
- OWASP Application Security Verification Standard (ASVS) 5.0.0, Mai 2025, aus OWASP/ASVS: © 2008-2025 The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in Abschnitte aufgeteilt und in das GRCA-Format umgewandelt, der Wortlaut unverändert. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Mobile Application Security Verification Standard (MASVS) v2.1.0, Januar 2024, aus OWASP/masvs: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Mobile Application Security Weakness Enumeration (MASWE) v1.0.0, August 2026, aus OWASP/maswe: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert, mit den MASVS-Controls verknüpft, denen sie zugeordnet sind. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Mobile Application Security Testing Guide (MASTG) v2.0.0, Juni 2026, aus OWASP/mastg: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Nur die Tests und Best Practices, ohne Codebeispiele, Bilder, Werkzeuge und Apps. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert; Verweise auf andere Seiten des MASTG als Links zu mas.owasp.org; die Schwachstelle jedes Tests in der Nummerierung der MASWE v1 und mit ihr verknüpft. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Software Assurance Maturity Model (SAMM) v2.2.0, Juli 2026, aus owaspsamm/core: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert; Kürzel (G-SM-1-A) aus dem Modell gebildet, die Assessment-Fragen als Prüfverfahren ihrer Aktivitäten. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Top 10:2025, aus OWASP/Top10: © 2003-2025 The OWASP® Foundation, Inc., lizenziert unter CC BY-SA 4.0. Die zehn Kategorien, ohne die Symbole. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0. Die Namen der zugeordneten CWEs (Common Weakness Enumeration): © 2006–2026 The MITRE Corporation. MITRE erlaubt die Nutzung für Forschung, Entwicklung und kommerzielle Zwecke, wenn jede Kopie den Urheberrechtsvermerk und die Lizenz enthält; maßgeblich ist der englische Wortlaut der Lizenz oben und die CWE Terms of Use. CWE™ ist eine Marke der MITRE Corporation.