Session Fixation in Feathersjs with Basic Auth

Session fixation occurs when an application accepts an attacker-supplied session identifier. In Feathersjs with Basic Auth, this risk arises from the mismatch between how authentication is performed and how session identifiers are managed. Feathersjs is commonly used with transport layers such as Express, and when session cookies are used, the framework does not inherently rotate or issue a new session identifier after successful authentication. If a user logs in using Basic Auth over a non-HTTPS connection, the Authorization header is sent on every request, but the session cookie established before login remains tied to the client. An attacker can craft a link that sets a known session cookie, then trick a victim into authenticating with Basic Auth. Because Feathersjs does not automatically invalidate or replace the session cookie after Basic Auth validation, the authenticated session remains bound to the attacker-chosen identifier, enabling the attacker to hijack the post-login session.

Basic Auth itself does not create a session; it is a stateless challenge-response mechanism. However, when combined with cookie-based sessions in Feathersjs, the statefulness of the session layer introduces a fixation surface. If the server issues a session cookie before authentication and reuses it after Basic Auth succeeds, the fixed session ID persists. This is particularly risky when session cookies lack the Secure and HttpOnly flags, or when HTTPS is not enforced end-to-end. Furthermore, if Feathersjs services are exposed as unauthenticated endpoints during the scan phase, an attacker can probe for session fixation behavior by observing whether the session identifier changes post-login. The presence of session cookies in an API-like setup may also indicate stateful behavior that deviates from RESTful expectations, increasing the attack surface. The risk is compounded if the Basic Auth credentials are reused across multiple clients or if the server does not enforce strict origin and referer checks, allowing cross-site request forgery to aid fixation.

Remediation focuses on ensuring that authentication does not preserve an attacker-controlled session identifier and that credentials are handled securely. The following approaches assume you are using Feathersjs with Express-style middleware and transport layers.

• Force session regeneration after successful Basic Auth login. If you rely on cookie-based sessions, replace the session cookie before accepting any authenticated state. Example using express-session with Feathersjs:

const session = require('express-session');
const MemoryStore = require('memorystore')(session);

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

app.use((req, res, next) => {
  if (req.isAuthenticated() && !req.session.regenerated) {
    req.session.regenerated = true;
    req.session.regenerate(err => {
      if (err) return next(err);
      // Move authenticated user data into the new session
      req.session.user = req.user;
      next();
    });
  } else {
    next();
  }
});

• Avoid using sessions entirely for APIs that rely on Basic Auth. Prefer token-based stateless authentication. If you must keep sessions, ensure that the login route explicitly clears any pre-authentication cookie and sets a new one with strict flags. Example of a login handler that discards an existing cookie and issues a new one:

app.post('/login', (req, res) => {
  const { username, password } = req.body;
  if (!username || !password) {
    return res.status(400).send('Missing credentials');
  }
  // Validate credentials against your user store
  if (isValidUser(username, password)) {
    // Clear any pre-existing session cookie
    res.clearCookie('connect.sid', { path: '/', secure: true, httpOnly: true, sameSite: 'strict' });
    const newSession = generateSessionForUser(username);
    res.cookie('connect.sid', newSession.id, {
      httpOnly: true,
      secure: true,
      sameSite: 'strict',
      maxAge: 24 * 60 * 60 * 1000
    });
    return res.send({ authenticated: true });
  }
  res.status(401).send('Invalid credentials');
});

• Enforce HTTPS and mark all cookies as Secure. Basic Auth credentials must never travel over unencrypted channels. Configure your transport or reverse proxy to terminate TLS and instruct Feathersjs to trust the proxy headers if necessary, but ensure that session cookies are only sent over HTTPS.
• Set appropriate CORS and headers to reduce cross-origin leakage. Use the Feathersjs hooks system to validate origins and strip sensitive headers on error responses. Example hook to mitigate cross-origin session fixation:

const cors = require('@feathersjs/configuration').cors;
app.configure(cors({
  origin: 'https://your-trusted-domain.com',
  credentials: true
}));

app.hooks({
  after: {
    all: [context => {
      const res = context.result;
      if (res && res.headers) {
        res.headers['Strict-Transport-Security'] = 'max-age=31536000; includeSubDomains';
        res.headers['X-Content-Type-Options'] = 'nosniff';
        res.headers['X-Frame-Options'] = 'DENY';
      }
      return context;
    }]
  }
});

• Audit and rotate session secrets regularly. If you use server-side sessions, ensure the session store and secret are rotated periodically and that old sessions are invalidated after rotation.