Identification and Authentication Failures is the risk that an application cannot reliably confirm who a user is, protect their credentials, or manage their session safely, and it ranks number seven in the OWASP Top 10 (2021). Previously the number-two category under the name "Broken Authentication," it slid down the list as standardized frameworks and managed identity providers made robust authentication easier to adopt. It stays dangerous because authentication is the gate in front of everything else: a single bypass, a reused session token, or a brute-forced password hands an attacker a legitimate identity, and every access-control check downstream then works perfectly in the attacker's favor.
What OWASP A07 actually covers
The category spans the full lifecycle of proving and maintaining identity. An application is vulnerable when it permits automated attacks such as credential stuffing (replaying username and password pairs leaked from other breaches) or brute forcing; when it permits default, weak, or well-known passwords like "Password1" or "admin"; when it uses weak or ineffective credential-recovery flows such as knowledge-based answers; when it stores passwords in plaintext or with fast, unsalted hashes; when multi-factor authentication is missing or can be skipped; when it exposes the session identifier in the URL; or when it fails to rotate session identifiers after login and fails to invalidate them at logout or after inactivity. The mapped weaknesses include CWE-287 (improper authentication), CWE-384 (session fixation), and CWE-297 (improper certificate validation), among more than twenty CWEs in total.
Why it ranks number seven
The demotion from second to seventh is a genuine success story rather than a downgrade in severity. Widespread adoption of identity platforms, single sign-on, and framework-provided session handling means fewer teams hand-roll the fragile authentication code that dominated a decade ago. Even so, the category still appeared in roughly 3.5 percent of tested applications, and its maximum incidence rate remained high, because the remaining failures tend to be catastrophic. Authentication has no partial credit: a login that can be bypassed once is bypassed for everyone.
Real-world examples
CVE-2022-1388 is a textbook total failure: an authentication bypass in the F5 BIG-IP iControl REST interface, rated CVSS 9.8, let an unauthenticated attacker send crafted requests to the management endpoint and execute arbitrary system commands as root. There was no credential to guess because the check could be skipped entirely. The Colonial Pipeline incident of 2021 shows the human side of the same category: attackers logged into a legacy VPN account using a single password recovered from a credential dump, and because that account had no multi-factor authentication enabled, one leaked secret was enough to halt fuel distribution across much of the United States East Coast. One flaw was a code bypass, the other a missing control, but both are the A07 signature: the system trusted an identity it should never have accepted.
Vulnerable versus fixed code
The most common A07 mistake in application code is comparing credentials naively and letting attackers guess without limit.
// VULNERABLE: plaintext comparison, no rate limiting, timing leaks
app.post('/login', async (req, res) => {
const user = await db.findUser(req.body.username);
if (user && user.password === req.body.password) {
req.session.userId = user.id; // session id never rotated
return res.send('ok');
}
return res.status(401).send('bad credentials');
});
// FIXED: slow salted hash, constant-time compare, lockout, session rotation
app.post('/login', rateLimit({ max: 5, windowMs: 60000 }), async (req, res) => {
const user = await db.findUser(req.body.username);
const ok = user && await bcrypt.compare(req.body.password, user.passwordHash);
if (!ok) return res.status(401).send('bad credentials');
await req.session.regenerate(); // prevents session fixation
req.session.userId = user.id;
return res.send('ok');
});
Storing a bcrypt (or argon2) hash instead of the password defeats offline cracking after a database leak, bcrypt.compare avoids the timing side channel of a raw string comparison, the rate limiter blunts brute force and credential stuffing, and regenerating the session on login closes the session-fixation window.
Prevention checklist
- Enforce multi-factor authentication wherever possible, and never allow it to be silently skipped for legacy accounts.
- Store passwords with a slow, salted, adaptive hash such as argon2 or bcrypt, never plaintext or fast unsalted digests.
- Rate-limit and progressively delay failed logins to defeat brute force and credential stuffing.
- Screen new passwords against known-breached password lists and reject weak or default values.
- Generate session identifiers server-side, keep them out of URLs, rotate them on login, and invalidate them on logout and timeout.
- Harden credential-recovery flows; avoid knowledge-based questions and use time-limited, single-use tokens.
- Prefer a vetted identity provider or framework over hand-rolled authentication code.
- Log authentication events so anomalies are visible, which ties directly into the monitoring covered by OWASP A09.
How Safeguard helps
Authentication failures live in running behavior, so Safeguard's DAST engine exercises your live application the way an attacker would, probing login, session, and recovery flows for bypasses, missing rate limits, session identifiers in URLs, and tokens that survive logout. When a weakness comes from a vulnerable authentication or session library rather than your own code, the SCA engine flags the affected component and its advisory. Griffin AI then explains the finding in context and proposes a concrete fix, whether that is enforcing MFA, swapping a weak hash, or regenerating sessions. See how reachability-first triage compares to alert-count scanners on our comparison against Snyk, and review coverage by tier on the pricing page.
Frequently Asked Questions
What is the difference between authentication and authorization?
Authentication confirms who you are; authorization decides what you are allowed to do. OWASP A07 covers failures in the first, such as accepting a guessed password or a stale session, while OWASP A01 (Broken Access Control) covers failures in the second. They are distinct gates, and a break in either is enough to compromise an account, which is why both sit in the Top 10.
Does adding multi-factor authentication fix this category on its own?
MFA is one of the highest-value controls, and it would have stopped the Colonial Pipeline intrusion, but it is not a complete answer. You still need slow password hashing, rate limiting, safe session handling, and hardened recovery flows, because attackers pivot to whichever control is weakest. MFA that can be bypassed on legacy accounts or skipped during recovery provides far less protection than its presence suggests.
Why is credential stuffing so effective against otherwise secure apps?
Because it does not attack your password rules at all; it replays real username and password pairs that users reused from a site that was already breached. Your login logic can be flawless and still admit an attacker who supplies genuine credentials. Defending against it requires rate limiting, breached-password screening, MFA, and anomaly detection rather than stronger complexity requirements.
Is storing passwords with fast hashing like SHA-256 good enough?
No. Fast hashes are designed for speed, which is exactly what an attacker wants when cracking a leaked database with billions of guesses per second. Password storage needs a deliberately slow, salted, memory-hard algorithm such as argon2 or bcrypt, tuned so a single verification is cheap for you but each cracking attempt is expensive for an attacker.
Ready to test your authentication flows against real attacks? Start scanning at app.safeguard.sh/register, or read the setup guide at docs.safeguard.sh.