Session Fixation in Express with Api Keys

Session fixation in Express becomes more nuanced when applications rely on API keys for authentication and session management. API keys are typically long-lived credentials intended for service-to-service or programmatic access, but when they are also used to identify or establish a user session, they can enable fixation-style attacks. In this context, fixation occurs when an attacker sets or predicts a session identifier or key value and then tricks a victim into using that same identifier, thereby hijacking the victim’s authenticated session.

Consider an Express API that accepts an API key via a request header (e.g., x-api-key) and uses it to establish a server-side session or to look up authorization context. If the server does not validate the provenance of the key and does not rotate or bind the key to a specific client session, an attacker can craft a request with a chosen API key, obtain a session token or cookie from the server, and then lure a victim into making requests with that same key. Because the server ties authorization and session state to the static key, the victim’s requests are treated as belonging to the attacker.

In a black-box scan, middleBrick tests API endpoints that accept API keys and examines whether session identifiers, tokens, or cookies can be influenced or preserved across requests. One of the 12 parallel security checks, Authentication, specifically looks for weak session binding and improper key handling. If an endpoint reflects or reuses an API key as a session token without regeneration or verification, the scan can flag this as a potential authorization issue (BOLA/IDOR) and surface risks tied to unauthenticated or predictable session contexts.

Real-world attack patterns mirror classic OWASP API Top 10 authentication flaws. For example, if an endpoint issues a JWT or session cookie after validating an API key without ensuring key uniqueness per session, an attacker can reuse a known key to maintain access. Data exposure checks may also reveal that keys are logged or transmitted without encryption, further increasing risk. The presence of unauthenticated LLM endpoints or improper input validation can compound the issue by allowing injection or manipulation of key-related parameters.

Because API keys are often treated as bearer credentials, it is critical to ensure they are never used as a direct replacement for dynamic session tokens without additional binding and rotation. middleBrick’s cross-referencing of OpenAPI specifications with runtime findings helps identify mismatches between declared authentication schemes and actual behavior, such as missing state changes after key validation.

Remediation focuses on preventing static API keys from being used as session identifiers and ensuring proper separation between authentication credentials and session state. Always treat API keys as secrets that authenticate the client or service, not as session tokens. Use middleware to validate keys and then establish independent, short-lived session tokens or JWTs that are bound to the authenticated context.

The following Express example demonstrates secure handling of API keys. The API key is validated against a store (simulated here with a Map), and upon success, the server issues a signed JWT with a short expiration. The JWT is then used for subsequent authorization, rather than reusing the raw API key as a session token.

const express = require('express');
const jwt = require('jsonwebtoken');
const app = express();

app.use(express.json());

const API_KEYS = new Map([
  ['public-key-abc123', { clientId: 'tenant-1', scopes: ['read'] }],
  ['internal-key-xyz789', { clientId: 'service-a', scopes: ['read', 'write'] }]
]);

const JWT_SECRET = process.env.JWT_SECRET || 'replace-with-secure-secret';

function authenticateApiKey(req, res, next) {
  const key = req.header('x-api-key');
  if (!key) {
    return res.status(401).json({ error: 'missing_api_key' });
  }
  const client = API_KEYS.get(key);
  if (!client) {
    return res.status(403).json({ error: 'invalid_api_key' });
  }
  // Bind client metadata to request for downstream use
  req.client = client;
  next();
}

function issueSessionToken(req, res) {
  const { client } = req;
  const sessionToken = jwt.sign(
    { sub: client.clientId, scopes: client.scopes },
    JWT_SECRET,
    { expiresIn: '15m' }
  );
  res.json({ session_token: sessionToken });
}

app.post('/login', authenticateApiKey, issueSessionToken);

// Protected route example
function verifySession(req, res, next) {
  const auth = req.header('authorization');
  if (!auth || !auth.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'missing_bearer_token' });
  }
  const token = auth.slice(7);
  jwt.verify(token, JWT_SECRET, (err, payload) => {
    if (err) return res.status(403).json({ error: 'invalid_token' });
    req.user = payload;
    next();
  });
}

app.get('/data', verifySession, (req, res) => {
  res.json({ message: 'secure data', for: req.user.sub });
});

app.listen(3000, () => console.log('API running on port 3000'));

Additional measures complement code changes. Use environment variables to manage secrets, enforce HTTPS to prevent interception, and apply strict input validation on all key-related parameters. Configure rotation policies for API keys and session tokens, and ensure that responses do not leak keys or session identifiers in logs or error messages. middleBrick’s CLI can be used in scripts to validate these patterns, while the GitHub Action can fail builds if insecure key handling is detected in endpoint definitions.

For continuous assurance, the Pro plan enables scheduled scans and alerts, so new endpoints or changes to authentication flows are evaluated for fixation risks before deployment. The MCP Server allows AI coding assistants to invoke scans during development, helping catch improper key usage early. By separating authentication credentials from session tokens and issuing short-lived, scoped tokens, you reduce the attack surface associated with static API keys in Express applications.