HIGH http request smugglingfeathersjsbasic auth

Http Request Smuggling in Feathersjs with Basic Auth

Http Request Smuggling in Feathersjs with Basic Auth — how this specific combination creates or exposes the vulnerability

HTTP Request Smuggling can occur in Feathers.js applications that use Basic Auth and a misconfigured HTTP proxy or load balancer. Feathers.js is a framework that typically runs on Node.js with an underlying HTTP server (for example, an Express-compatible server). When a Feathers service is protected with HTTP Basic Auth at the edge (e.g., via a reverse proxy or API gateway) rather than enforced consistently in application code, the proxy and the Feathers server may interpret the request stream differently. This mismatch can allow an attacker to smuggle a request across security boundaries by manipulating headers such as Content-Length and Transfer-Encoding.

Consider a deployment where a proxy terminates TLS and adds Basic Auth headers before forwarding to the Feathers app, or where the Feathers server itself applies Basic Auth via middleware. If the proxy normalizes or strips certain headers and the Feathers server parses the raw request stream, an attacker can craft a request that is interpreted as two separate requests by the two endpoints. For example, a request with both Content-Length and Transfer-Encoding headers may be processed by the proxy as a single, valid request, while the Feathers server parses the second request independently. This second request may bypass the Basic Auth check if the proxy fails to reapply credentials for the smuggled request.

In the context of middleBrick’s checks, this appears as a BOLA/IDOR or BFLA/Privilege Escalation finding when unauthenticated smuggling techniques allow access to authenticated-only endpoints. The scanner also flags missing strict header canonicalization and inconsistent authentication enforcement between edge layers and the Feathers application. Attack patterns relevant here include TECLAW and CLAUDIUS-style smuggling that exploit differences in how headers are interpreted. Because Feathers services often expose REST-like endpoints for CRUD operations, a smuggled request can perform unauthorized create, read, update, or delete actions if the application does not enforce authentication and authorization uniformly.

To detect this, middleBrick scans the unauthenticated attack surface and correlates runtime behavior with OpenAPI/Swagger definitions (including $ref resolution). If your API specification defines security schemes using Basic Auth and the runtime allows smuggling-prone header combinations, the tool reports a high-severity finding with remediation guidance. Note that middleBrick detects and reports these risks but does not fix or block requests; it provides actionable guidance to help developers adjust header handling and authentication placement.

Basic Auth-Specific Remediation in Feathersjs — concrete code fixes

Remediation focuses on ensuring authentication is enforced consistently within the Feathers application layer and that header parsing is strict. Avoid relying solely on edge-layer Basic Auth without validating credentials in Feathers middleware. Use Feathers hooks to verify the Authorization header on every request and ensure the server does not accept ambiguous transfer encodings.

Below is a syntactically correct example of Basic Auth enforcement in a Feathers.js service using hooks. This approach validates credentials on each request, independent of any proxy assumptions.

// src/hooks/basic-auth.js
const basicAuth = require('basic-auth');

const checkAuth = (options) => {
  return (context) => {
    const credentials = basicAuth(context.req);
    const validUser = 'admin';
    const validPass = 's3cur3P@ss!';

    if (!credentials || credentials.name !== validUser || credentials.pass !== validPass) {
      throw new Error('Not authorized');
    }
    // Optionally attach user to context for downstream hooks/services
    context.params.authUser = credentials.name;
    return context;
  };
};

module.exports = { checkAuth };

Apply the hook in your service definition:

// src/services/items/index.js
const { checkAuth } = require('../../hooks/basic-auth');

module.exports = function (app) {
  const options = {
    name: 'items',
    paginate: { default: 10, max: 25 }
  };

  app.use('/items', {
    find(params) {
      // simplified example; in practice use a Model or adapter
      return Promise.resolve({
        total: 0,
        limit: 10,
        skip: 0,
        data: []
      });
    },
    create(data, params) {
      // Ensure authenticated context
      if (!params.authUser) {
        return Promise.reject(new Error('Not authorized'));
      }
      // business logic here
      return Promise.resolve(data);
    }
  });

  app.service('items').hooks({
    before: {
      all: [checkAuth()],
      find: [],
      get: [],
      create: [],
      update: [],
      patch: [],
      remove: []
    }
  });
};

Additionally, harden your server to prevent smuggling by rejecting requests that contain both Content-Length and Transfer-Encoding headers. You can do this at the Node.js HTTP layer before requests reach Feathers middleware:

// server.js (Node.js raw server before mounting Feathers)
const http = require('http');

const server = http.createServer((req, res) => {
  const hasTE = req.headers['transfer-encoding'];
  const hasCL = req.headers['content-length'];
  if (hasTE && hasCL) {
    res.statusCode = 400;
    res.end('Bad Request: ambiguous transfer encodings');
    return;
  }
  // Pass to Feathers server
  app(req, res);
});

server.listen(3030);

These steps align with remediation guidance provided by middleBrick when its scans identify smuggling risks combined with Basic Auth configurations. By enforcing authentication in hooks and normalizing headers, you reduce the attack surface regardless of deployment topology.

Frequently Asked Questions

Why does using Basic Auth at the proxy alone not prevent Request Smuggling in Feathers.js?
Because proxies may normalize or strip headers differently than the Feathers server parses them. If the Feathers application does not independently validate credentials and reject ambiguous transfer encodings (Content-Length + Transfer-Encoding), a smuggled request can bypass the proxy's auth check.
How does middleBrick detect Http Request Smuggling risks related to Basic Auth in Feathersjs?
middleBrick runs parallel security checks including BOLA/IDOR and BFLA/Privilege Escalation while analyzing OpenAPI/Swagger specs with full $ref resolution. It correlates unauthenticated smuggling probes with authentication enforcement points and flags high-severance findings when smuggling techniques could bypass Basic Auth protections.