Identification and Authentication Failures

URL: trusteed.io/academy/web-security/identification-and-authentication-failures

Identification and Authentication Failures cover weaknesses in how a web application confirms a user's identity and manages their session afterward — beyond login mechanics alone, this category includes session fixation, session tokens exposed in URLs, missing session invalidation, and credential-related weaknesses across the full identity lifecycle. It was renamed from "Broken Authentication" in the 2021 revision to more clearly include identity and session management, not authentication alone.

What Is This Category?

Where the OWASP API Security Top 10's Broken Authentication (API2) focuses tightly on token/JWT mechanics for APIs, this category takes the broader web-application view of the entire identity lifecycle: credential stuffing and brute force resistance, session identifier handling (how session tokens are generated, stored, and transmitted), session fixation (allowing an attacker to set a victim's session ID before authentication, then hijacking the now-authenticated session), and proper session termination on logout, password change, or extended inactivity.

Why AI Coding Assistants Get This Wrong

Session management is frequently handled by framework defaults that developers rarely inspect closely — an assistant scaffolding a login flow with a standard session middleware will produce something that "just works," including default session cookie settings that may not set Secure, HttpOnly, or SameSite attributes explicitly, and default session regeneration behavior that may not actually rotate the session ID on login (leaving a session-fixation opening). None of these gaps prevent a functional login flow from working correctly in testing — they only matter under an active attack scenario a quick functional test never simulates.

Vulnerable Pattern

// Session ID accepted from the client and never regenerated on login — session fixation risk
app.post('/login', async (req, res) => {
  const user = await authenticateUser(req.body.email, req.body.password);
  if (user) {
    req.session.userId = user.id; // reuses whatever session ID already existed, even if attacker-set
    res.json({ success: true });
  }
});

// Default cookie settings — no Secure, HttpOnly, or SameSite specified
app.use(session({ secret: 'keyboard cat', resave: false, saveUninitialized: true }));

Secure Pattern

app.use(session({
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false, // don't create sessions for unauthenticated visitors
  cookie: {
    secure: true,      // only sent over HTTPS
    httpOnly: true,     // inaccessible to client-side JavaScript
    sameSite: 'strict', // mitigates CSRF via cookie transmission
    maxAge: 15 * 60 * 1000,
  },
}));

app.post('/login', async (req, res) => {
  const user = await authenticateUser(req.body.email, req.body.password);
  if (user) {
    req.session.regenerate((err) => { // new session ID issued on successful login
      if (err) return res.status(500).json({ error: 'Login failed' });
      req.session.userId = user.id;
      res.json({ success: true });
    });
  } else {
    res.status(401).json({ error: 'Invalid credentials' });
  }
});

app.post('/logout', (req, res) => {
  req.session.destroy(() => res.json({ success: true })); // explicit invalidation, not just client-side cleanup
});

Copy-Paste Rules for Cursor, Claude Code, and Codex

---
description: Identification and authentication failures — session management for web applications
alwaysApply: true
---

# Identity and Session Management Rules

- Regenerate the session identifier immediately upon successful
  authentication (login, privilege change) to prevent session fixation —
  never continue using a pre-existing session ID after authenticating a user.
- Session cookies MUST set `Secure`, `HttpOnly`, and an appropriate
  `SameSite` attribute by default. Never rely on framework defaults without
  explicitly verifying these are set.
- Explicitly destroy the server-side session on logout — do not rely on
  client-side cookie deletion alone, which leaves the session valid
  server-side if the token is captured before deletion.
- Never transmit session identifiers or authentication tokens in URL query
  strings, since URLs are commonly logged, cached, and shared,
  inadvertently exposing the token.
- Set explicit, reasonably short session expiration and enforce
  re-authentication for sensitive actions after a period of inactivity —
  do not use indefinite or very long-lived sessions by default.
- Apply rate limiting to login, password reset, and MFA verification
  endpoints to resist credential stuffing and brute-force attempts.
- When scaffolding session or authentication middleware, apply these
  settings explicitly in the same pass, rather than relying on a
  framework's out-of-the-box configuration.

Verification Checklist

• Session IDs are regenerated on every successful authentication event
• Session cookies set Secure, HttpOnly, and SameSite explicitly
• Logout explicitly destroys the server-side session, not just the client-side cookie
• No session identifiers or tokens are transmitted via URL parameters
• Session expiration is explicit and reasonably short; sensitive actions require re-authentication after inactivity
• Login, password reset, and MFA endpoints are rate-limited
• Runtime testing validates session handling under attack conditions — see Trusteed's WAAP platform for credential-stuffing and bot defense