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.