Session Fixation in Express with Cockroachdb

Session fixation occurs when an application allows an attacker to force a user’s session identifier to a known value. In Express, this typically happens when session identifiers are assigned before authentication and are not regenerated after login. When Express is paired with Cockroachdb as the session store, the risk pattern shifts because session data is persisted in a distributed SQL database rather than in memory or a simple key-value store.

Consider an Express app using a Cockroachdb-backed session store without proper session regeneration on authentication. An attacker can craft a link like https://example.com/login?session_id=attacker123. If the app initializes a session ID from a query parameter or does not rotate the session ID after login, the authenticated session will retain attacker123. Because Cockroachdb retains session rows across nodes and survives restarts, the attacker can later use the same session ID to hijack the authenticated user’s session once they log in.

With Cockroachdb, session records are stored in a durable table with a primary key such as session ID. If Express creates a session record in Cockroachdb before authentication and never updates the key, the attacker’s prior session ID remains valid post-login. Moreover, if session cookies lack Secure and HttpOnly flags, or if they are transmitted over unencrypted channels, the fixed session ID can be intercepted. Cockroachdb’s strong consistency across regions does not mitigate this; it only ensures that the attacker’s session row remains consistent and available, increasing the window for exploitation.

Another vector involves predictable session IDs. If the session ID is generated using a weak entropy source (e.g., Math.random()), an attacker can brute-force valid session IDs. Cockroachdb will store each attempted session as a row, and because it supports high write throughput, an attacker can flood the table with guessed session IDs. Later, they can poll the database for newly authenticated sessions by checking for rows updated after login timestamps, effectively coupling session fixation with enumeration.

Finally, improper session invalidation exacerbates the issue. When a user logs out, Express must delete or expire the session row in Cockroachdb. If the application only clears the cookie client-side but leaves the server-side session record intact, an attacker who previously obtained the session ID can reuse it until the Cockroachdb TTL garbage collection runs. This persistence amplifies the impact of fixation compared to in-memory stores where sessions evaporate on restart.

To mitigate session fixation in Express with Cockroachdb, focus on session lifecycle management and strict cookie policies. Always regenerate the session ID after successful authentication and ensure session rows in Cockroachdb are updated atomically.

Example using the connect-pg-simple-style pattern adapted for Cockroachdb with pg:

const express = require('express');
const session = require('express-session');
const { Client } = require('pg');

const client = new Client({
  connectionString: process.env.COCKROACHDB_URL,
  ssl: { rejectUnauthorized: false }
});

await client.connect();

// Ensure the sessions table exists (Cockroachdb compatible)
await client.query(`
  CREATE TABLE IF NOT EXISTS sessions (
    id TEXT PRIMARY KEY,
    sess JSONB NOT NULL,
    expires TIMESTAMP WITH TIME ZONE NOT NULL
  )
`);

app.use(session({
  store: new (require('connect-session-sequelize'))(session.Store), // adapt or use custom store
  client: client,
  name: '__Host-session',
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    maxAge: 24 * 60 * 60 * 1000
  }
}));

app.post('/login', async (req, res) => {
  const { username, password } = req.body;
  // validate credentials against your user table
  const user = await validateUser(username, password);
  if (!user) return res.status(401).send('Invalid credentials');

  // Critical: regenerate session to prevent fixation
  req.session.regenerate((err) => {
    if (err) return res.status(500).send('Session error');
    req.session.userId = user.id;
    req.session.authenticated = true;
    // Save explicitly if using custom store
    req.session.save(() => {
      res.clearCookie('__Host-session');
      res.cookie('__Host-session', req.session.id, {
        httpOnly: true,
        secure: true,
        sameSite: 'lax',
        path: '/'
      });
      res.redirect('/dashboard');
    });
  });
});

app.post('/logout', (req, res) => {
  const sid = req.session.id;
  req.session.destroy((err) => {
    if (err) console.error('Session destroy error', err);
    // Remove server-side Cockroachdb record
    client.query('DELETE FROM sessions WHERE id = $1', [sid])
      .catch(console.error);
    res.clearCookie('__Host-session');
    res.sendStatus(200);
  });
});

Key points:

Call req.session.regenerate() before setting any authenticated data. This creates a new session ID and a new Cockroachdb row, breaking the attacker’s fixed ID.
Use cookie flags: __Host- prefix enforces Secure, HttpOnly, and same-site defaults. Set secure: true in production to prevent transmission over HTTP.
Set saveUninitialized: false to avoid creating session rows for unauthenticated visitors, reducing noise in Cockroachdb and limiting exposure surface.
Explicitly delete the Cockroachdb session row on logout to prevent reuse; rely on TTL only if your store supports automatic expiration.

For custom stores, ensure the update operation is atomic. When rotating the session ID, write a new row and delete the old one within a transaction if your access pattern requires strong consistency.