Session Fixation in Express with Basic Auth

Session fixation occurs when an application allows an attacker to force a user’s session identifier to a known value. In Express applications that rely on HTTP Basic Authentication without additional session management, the risk is nuanced: the browser itself sends credentials with each request, and there is typically no server-side session ID to fix. However, developers often introduce session state on top of Basic Auth (for example, to implement login-time checks, MFA, or coarse authorization tiers). If session identifiers are issued before authentication, or if an authenticated session is reused across users without re-authentication, fixation-like conditions can arise.

Consider an Express route that creates a session cookie immediately on a request that includes Basic Auth headers. If the application does not re-validate credentials and issue a new session after login, an attacker who knows or sets the session identifier can trick a victim into authenticating with that same identifier. Because Basic Auth transmits credentials on every request, an attacker may also capture credentials via passive sniffing or via insecure logging. Additionally, reports from scans run by middleBrick can surface related findings such as Missing Authentication for sensitive endpoints or weak Transport protections, which compound risks when combined with weak session practices.

Furthermore, if the application exposes an unauthenticated endpoint that reveals user context (e.g., current username derived from Basic Auth and stored in the session), an attacker may enumerate valid accounts or infer authorization boundaries. This intersects with BOLA/IDOR patterns when session identifiers map directly to authorization checks without re-verifying the authenticated identity. middleBrick’s checks for Authentication and Property Authorization are designed to detect such gaps by correlating runtime behavior with spec definitions, including $ref resolution in OpenAPI documents.

Remediation focuses on ensuring each authenticated interaction revalidates credentials and does not rely on a pre-assigned session identifier for authorization. Avoid issuing a session cookie before successful authentication, and if you must maintain session state, re-validate the Authorization header on sensitive operations.

Example: Unsafe session creation before auth check

const express = require('express');
const cookieParser = require('cookie-parser');
const app = express();
app.use(cookieParser());

// Unsafe: session created before verifying credentials
app.get('/profile', (req, res) => {
  if (!req.session.user) {
    req.session.user = req.headers['authorization']; // storing raw header
  }
  res.json({ user: req.session.user });
});

Example: Secure pattern with Basic Auth validation on each request

const express = require('express');
const cookieParser = require('cookie-parser');
const app = express();
app.use(cookieParser());

// Hardcoded user store for example; use a secure store in production
const USERS = {
  alice: Buffer.from('alice:password123').toString('base64'),
  bob: Buffer.from('bob:secret').toString('base64')
};

// Middleware to validate Basic Auth on sensitive routes
function basicAuthMiddleware(req, res, next) {
  const header = req.headers['authorization'];
  if (!header || !header.startsWith('Basic ')) {
    res.set('WWW-Authenticate', 'Basic realm="Secure Area"');
    return res.status(401).send('Authentication required');
  }
  const token = header.split(' ')[1];
  const valid = Object.values(USERS).some(expected => expected === token);
  if (!valid) {
    return res.status(401).send('Invalid credentials');
  }
  // Re-derive identity safely instead of trusting session
  const decoded = Buffer.from(token, 'base64').toString('utf8');
  const [username] = decoded.split(':');
  req.user = username;
  next();
}

// Apply to sensitive routes
app.get('/profile', basicAuthMiddleware, (req, res) => {
  // Do not store raw auth in session; use req.user derived from validated credentials
  res.json({ user: req.user });
});

// Example of avoiding fixation: issue no session until truly needed
app.post('/login', basicAuthMiddleware, (req, res) => {
  // If you must use sessions, set after successful auth and rotate identifiers
  req.session.regenerate(err => {
    if (err) return res.status(500).send('Cannot create session');
    req.session.user = req.user;
    res.clearCookie('connect.sid'); // ensure previous identifiers are cleared
    res.json({ session: 'new', user: req.user });
  });
});

Operational recommendations

• Always require authentication headers on sensitive endpoints; do not rely on session cookies alone.
• If using sessions, regenerate session identifiers after authentication (session.regenerate) and clear old cookies.
• Do not store raw Authorization headers in session state; derive a minimal identity and re-validate when necessary.
• Use HTTPS to protect credentials in transit and avoid logging Authorization headers.
• Leverage scans from middleBrick to detect missing authentication on admin or sensitive routes and to validate that Authorization checks align with your OpenAPI spec definitions.