Session fixation protection is in place

Session fixation (CWE-384, CAPEC-61) lets an attacker plant a known session token in a victim's browser before login, then use that same token after the victim authenticates. The attacker never needs to steal anything — they supplied the token themselves. This attack predates modern auth libraries and is largely invisible in code review because the vulnerability is an absence: the session is never regenerated after login. OWASP A07 (Identification and Authentication Failures) lists session fixation as a named failure mode, and the OWASP ASVS Session Management chapter requires that session identifiers be regenerated on authentication.

After successful credential verification, always replace the pre-login session with a freshly generated one before setting any user data on it:

// Express/Fastify — regenerate before setting user data
app.post('/login', async (req, res) => {
  const user = await verifyCredentials(req.body)
  if (!user) return res.status(401).json({ error: 'Invalid credentials' })
  req.session.regenerate((err) => {
    if (err) return res.status(500).json({ error: 'Session error' })
    req.session.userId = user.id
    req.session.save(() => res.json({ ok: true }))
  })
})

Managed libraries (NextAuth, Clerk, Supabase Auth) regenerate sessions after login by design. If you have overridden the session token generation logic in any of these libraries, revert to the default.