Http Request Smuggling in Express with Bearer Tokens

HTTP request smuggling occurs when an attacker can craft requests that are interpreted differently by a frontend proxy/load balancer and your Express backend. In Express, this typically involves discrepancies in how Transfer-Encoding and Content-Length headers are handled. When Bearer Tokens are involved, smuggling can expose token leakage, authentication bypass, or request tampering because the token travels in headers that may be parsed inconsistently across layers.

Consider an Express app that accepts Authorization headers with Bearer tokens and passes requests to an upstream service or processes them after middleware. If Express is placed behind a reverse proxy that parses Transfer-Encoding: chunked differently than Express’s built-in body parser, an attacker may smuggle a second request through to the backend or to another downstream listener. For example, a request with both Transfer-Encoding: chunked and Content-Length can cause the proxy to treat the first request as valid while Express interprets the smuggled portion as a new request, potentially inheriting the Authorization header with the Bearer token. This can lead to token exposure in logs or unintended authenticated actions, violating the principle of separation between authentication boundary and request routing.

In the context of the 12 parallel checks run by middleBrick, this vulnerability would appear under BOLA/IDOR, Input Validation, and Unsafe Consumption categories. The scanner tests whether header parsing inconsistencies allow smuggling that bypasses authentication context, including Bearer token handling. Without proper header normalization and strict content-length validation in Express, an unauthenticated attacker can probe for these discrepancies and potentially intercept or manipulate requests containing sensitive tokens.

Remediation focuses on ensuring consistent header parsing and strict validation so that Bearer tokens are never subject to ambiguous interpretation by proxies or Express itself. Below are concrete Express patterns that reduce smuggling risk while safely handling Authorization headers.

1. Explicitly reject requests that mix Transfer-Encoding and Content-Length to prevent smuggling ambiguity:

// middleware/validateHeaders.js
function validateHeaders(req, res, next) {
  const hasTE = req.headers['transfer-encoding'];
  const hasCL = req.headers['content-length'];
  if (hasTE && hasCL) {
    return res.status(400).send('Invalid headers: Transfer-Encoding and Content-Length cannot both be present');
  }
  next();
}

const express = require('express');
const app = express();
app.use(validateHeaders);
app.use(express.json());

2. Normalize Authorization header casing and strictly validate Bearer tokens before routing or forwarding. This prevents case-mismatch smuggling and ensures tokens are only accepted in the expected format:

// middleware/auth.js
function normalizeBearerToken(req, res, next) {
  const auth = req.headers.authorization;
  if (auth && typeof auth === 'string') {
    const parts = auth.trim().split(' ');
    if (parts.length === 2 && parts[0].toLowerCase() === 'bearer') {
      req.token = parts[1];
      // Remove raw header to avoid downstream duplication or leakage
      delete req.headers.authorization;
    } else {
      return res.status(401).send('Unauthorized: malformed Authorization header');
    }
  } else {
    return res.status(401).send('Unauthorized: missing Authorization header');
  }
  next();
}

app.use(normalizeBearerToken);

3. Use strict JSON body parsing and avoid combining with urlencoded parsing when handling token-bearing requests. This reduces parsing layers that could be abused for smuggling:

// app.js
const express = require('express');
const app = express();

// Only parse JSON for routes that need it
app.use('/api/token-endpoint', express.json({ type: 'application/json' }));

// Do not use app.use(express.urlencoded({ extended: true })) globally if not required

4. When forwarding requests to upstream services, ensure the Authorization header is explicitly set and not passed through raw header smuggling vectors. Example of safe forwarding logic:

// routes/forward.js
const express = require('express');
const fetch = require('node-fetch');
const router = express.Router();

router.post('/proxy', async (req, res) => {
  const token = req.token; // normalized token from middleware
  const targetUrl = 'https://upstream.example.com/resource';
  try {
    const upstreamRes = await fetch(targetUrl, {
      method: req.method,
      headers: {
        Authorization: `Bearer ${token}`,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(req.body)
    });
    const data = await upstreamRes.text();
    res.status(upstreamRes.status).send(data);
  } catch (err) {
    res.status(502).send('Bad Gateway');
  }
});

app.use('/api', router);

These patterns ensure Bearer tokens are handled consistently, reducing the window for header-based smuggling. They align with input validation and unsafe consumption checks that middleBrick performs, highlighting areas where header ambiguity could lead to authentication bypass or token leakage.