Http Request Smuggling in Feathersjs with Api Keys

HTTP request smuggling arises when an API processes requests differently depending on whether they are fronted by a reverse proxy, load balancer, or API gateway. In FeathersJS applications that rely on API keys for client identification, the framework’s hook and service architecture can unintentionally allow ambiguous request parsing when multiple transports (HTTP/1.1, HTTP/2) and varying header handling are involved. If a FeathersJS app does not enforce strict header validation and message size limits, an attacker can craft requests that exploit differences in how the proxy and the FeathersJS server interpret Content-Length and Transfer-Encoding headers.

When API keys are passed in headers (e.g., x-api-key), the smuggling risk does not stem from the key itself being weak, but from how the key-bearing requests are handled in chained proxies. For example, a request with both Transfer-Encoding: chunked and Content-Length may be interpreted differently by the proxy versus the FeathersJS server. If the server processes one interpretation and the proxy another, an attacker can smuggle a request into or out of the application’s request stream. This can lead to request splitting, where a single TCP stream results in two logical requests, potentially allowing an attacker to inject an authenticated request (using a stolen API key) without it being rejected by the gateway.

In FeathersJS, services and hooks are typically mounted at paths like /api/v1/resources. If the application does not normalize or reject ambiguous messages before they reach the FeathersJS layer, a smuggled request can bypass intended routing and be processed by a service that trusts the API key context. Real-world attack patterns include CVE-classic request splitting scenarios where an unauthenticated backend processes a smuggled request containing an API key that was intended to be confined to a specific upstream service. Because FeathersJS does not inherently validate message boundaries when proxies are involved, developers must explicitly enforce strict header policies and message size limits to prevent the API key context from being abused via smuggled requests.

Remediation focuses on ensuring FeathersJS processes only well-formed requests and rejects ambiguous or malformed messages before they reach services or hooks. You should configure your reverse proxy or load balancer to reject requests that contain both Transfer-Encoding and Content-Length headers. Within FeathersJS, add hooks that sanitize and validate headers early in the request lifecycle, and enforce strict content-length checks for requests carrying API keys.

Below are concrete FeathersJS hook examples that demonstrate how to validate headers and reject suspicious requests. These hooks can be placed globally or on specific services that require API key authentication.

// src/hooks/validate-smuggling.js
module.exports = function validateSmuggling() {
  return async (context) => {
    const { headers } = context.params;
    // Reject requests that contain both Transfer-Encoding and Content-Length
    if (headers['transfer-encoding'] && headers['content-length']) {
      throw new Error('Invalid headers: Transfer-Encoding and Content-Length must not both be present');
    }
    // Normalize and explicitly drop dangerous headers
    delete headers['transfer-encoding'];
    // Optionally enforce a strict content-length for keyed requests
    if (headers['x-api-key'] && headers['content-length'] !== undefined) {
      const len = parseInt(headers['content-length'], 10);
      if (isNaN(len) || len < 0 || len > 10_000_000) { // adjust max as needed
        throw new Error('Invalid Content-Length');
      }
    }
    return context;
  };
};

Register the hook in your FeathersJS app so it runs before authentication and service execution:

// src/app.js
const feathers = require('@feathersjs/feathers');
const express = require('@feathersjs/express');
const validateSmuggling = require('./hooks/validate-smuggling');

const app = express(feathers());

// Apply globally to catch smuggling attempts before routing
app.hooks({
  before: {
    all: [validateSmuggling()]
  }
});

// Your existing API key authentication setup
app.configure(require('@feathersjs/authentication-local'));
app.use('/api/resources', require('./services/resources'));

module.exports = app;

Additionally, ensure your API key validation occurs after header normalization. For example, a robust authentication hook can verify the presence and format of the API key while relying on the earlier hook to ensure the request structure is not ambiguous:

// src/hooks/authenticate-key.js
module.exports = function authenticateKey() {
  return async (context) => {
    const { headers } = context.params;
    const key = headers['x-api-key'];
    if (!key || !/^[A-F0-9]{32}$/.test(key)) {
      throw new Error('Invalid or missing API key');
    }
    // Attach normalized identity to context for downstream services
    context.params.user = { apiKey: key };
    return context;
  };
};

Combine these hooks to create a layered defense: the smuggling-prevention hook normalizes and rejects malformed messages, while the authentication hook ensures only requests with properly formatted API keys proceed. This approach aligns with OWASP API Security Top 10’s requirements for strict input validation and robust authentication, reducing the risk of request smuggling when API keys are used for access control.