VNX-NODE-025 – Insecure express-session or cookie-session configuration

Overview

This rule detects express-session and cookie-session middleware configurations that weaken session cookie security by setting secure: false or httpOnly: false, and express-session configurations that never set cookie.secure (it defaults to false). The options may be inline or in an object assigned in the same file; secure: process.env.NODE_ENV === 'production', secure: 'auto' and a later sess.cookie.secure = true all count as set. cookie-session without an explicit secure is not reported, because it marks the cookie Secure on HTTPS requests itself. Test and example files are skipped. These settings control how browsers transmit and expose session cookies and represent the first line of defence against session hijacking attacks.

The secure flag instructs browsers to transmit the cookie only over HTTPS connections. When it is absent or set to false, the session cookie is sent with every HTTP request, including over unencrypted connections on coffee shop Wi-Fi, corporate proxies, or any network where traffic is intercepted. The httpOnly flag prevents JavaScript running in the page from reading the cookie via document.cookie, which limits the damage from XSS attacks — without it, a single reflected or stored XSS vulnerability gives an attacker immediate access to the victim’s session token.

Severity: Medium | CWE: CWE-614 – Sensitive Cookie in HTTPS Session Without ‘Secure’ Attribute

Why This Matters

Session token theft is one of the most common and impactful attack outcomes. An attacker who obtains a valid session token can impersonate the authenticated user for the lifetime of the session without knowing their password. Session tokens are high-value targets for both passive network sniffing and active XSS exploitation.

HTTP-only networks are more common than developers expect — developer laptops on internal networks, staging environments, HTTP→HTTPS redirects that fire after a cookie is already set, and load balancers that terminate TLS before the Node.js process. Without secure: true, session cookies leak in all of these scenarios.

The combination of secure: false and httpOnly: false is particularly dangerous: it allows both network interception and JavaScript theft, meaning a single vulnerability anywhere in the application can compromise every authenticated session.

What Gets Flagged

const session = require('express-session');
const cookieSession = require('cookie-session');

// FLAGGED: the secure:false line
app.use(session({
  secret: process.env.SESSION_SECRET,
  cookie: {
    httpOnly: true,
    secure: false, // TODO: enable once TLS is in front
  },
}));

// FLAGGED: the session( line; express-session defaults cookie.secure to false
app.use(session({ secret: process.env.SECRET, resave: false, saveUninitialized: false }));

// FLAGGED: httpOnly:false makes the cookie readable by page scripts
app.use(cookieSession({ name: 'session', keys: [process.env.KEY_A], httpOnly: false }));

Remediation

  1. Set cookie.secure: true and ensure the application is only accessible over HTTPS in production. Use an environment variable to conditionally allow false in local development.

  2. Set cookie.httpOnly: true (this is the default in express-session but should be set explicitly for clarity).

  3. Set cookie.sameSite: 'strict' or 'lax' to mitigate CSRF attacks using the session cookie.

  4. Set resave: false and saveUninitialized: false to reduce session store writes and avoid race conditions.

// SAFE: secure session configuration
const session = require('express-session');

app.use(session({
  secret:            process.env.SESSION_SECRET,
  resave:            false,
  saveUninitialized: false,
  cookie: {
    secure:   process.env.NODE_ENV === 'production', // HTTPS only in prod
    httpOnly: true,    // not accessible via document.cookie
    sameSite: 'strict', // CSRF mitigation
    maxAge:   3600000,  // 1 hour
  },
}));

References