Session Fixation in Feathersjs with Cockroachdb

Session fixation occurs when an application assigns a user a session identifier before authentication and does not regenerate that identifier afterward. In a Feathersjs application backed by Cockroachdb, this typically maps to how session identifiers are created, stored, and associated with user records in a distributed SQL store.

Feathersjs is framework-agnostic but often integrates with express-session or similar middleware. If the session ID is generated before login (for example, via a default cookie issued on every visit) and then persisted to Cockroachdb with the user ID only after authentication, the same session token can be reused across authentication boundaries. An attacker can set a victim’s session ID (e.g., by sending a link with a known cookie value) and later trick the victim into authenticating. Because Cockroachdb stores the session row keyed by that predictable ID, the attacker’s session maps to the victim’s authenticated account once the victim logs in.

The risk is compounded when session data is stored server-side in Cockroachdb and the session identifier is exposed in URLs, logs, or browser history. Because Cockroachdb is a distributed SQL database, replication and multi-region deployments can increase the window in which a stale or improperly invalidated session record remains accessible. If session records are not cleaned up promptly or if session IDs are predictable, an attacker who obtains a session token can maintain access even after the victim logs out, provided the token remains valid and the backend does not enforce regeneration on privilege changes.

In Feathersjs, this manifests when authentication hooks do not explicitly rotate the session token or when custom authentication logic reuses an existing session row instead of creating a new one. Because the framework does not mandate a particular session store, developers might rely on defaults that do not align with best practices for session lifecycle management in a strongly consistent store like Cockroachdb.

Remediation focuses on ensuring a new, unpredictable session identifier is issued immediately after successful authentication and that old session records are invalidated. The following example uses express-session with a Cockroachdb-backed store (e.g., using a compatible driver or an ORM like Sequelize where Cockroachdb is the target). It demonstrates generating a fresh session ID on login and binding it securely to the user.

const session = require('express-session');
const Sequelize = require('sequelize');
const CockroachStore = require('connect-cockroachdb')(session); // or use a compatible custom store

const sequelize = new Sequelize({
  dialect: 'postgres',
  host: 'your-cockroachdb-host',
  port: 26257,
  username: 'root',
  password: 'password',
  database: 'feathersdb',
  // Cockroachdb-specific options such as ssl and connection pooling go here
});

const sessionStore = new CockroachStore({ db: sequelize });

app.use(session({
  store: sessionStore,
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'strict',
  },
}));

// In your Feathersjs authentication hook (e.g., after hook)
app.service('authentication').hooks({
  after: {
    async create(context) {
      const { result } = context;
      if (result && result.accessToken) {
        // Regenerate session to prevent fixation
        await new Promise((resolve, reject) => {
          context.req.session.regenerate((err) => {
            if (err) return reject(err);
            context.req.session.userId = result.user.id;
            context.req.session.save(resolve);
          });
        });
      }
      return context;
    },
  },
});

Additionally, ensure session cleanup and invalidation on logout to remove stale records from Cockroachdb:

app.service('authentication').hooks({
  before: {
    logout(context) {
      // Explicitly destroy the server-side session record
      return new Promise((resolve, reject) => {
        context.req.session.destroy((err) => {
          if (err) return reject(err);
          resolve(context);
        });
      });
    },
  },
});

When using Feathersjs with authentication strategies that do not rely on cookies (e.g., JWT), session fixation is less relevant, but if you employ cookie-based sessions with Cockroachdb storage, the above patterns reduce the risk. For deployments that scale across regions, ensure session store operations are consistent and that TTL/expiry aligns with your security policy to avoid prolonged exposure of stale session rows.