Header Injection in Feathersjs with Api Keys

Header Injection in FeathersJS when using API keys can occur when user-controlled input is reflected into HTTP response headers without validation or sanitization. FeathersJS is a framework for real-time applications that typically exposes services via REST and WebSocket transports. API keys are often used to authenticate requests, commonly passed in headers such as x-api-key. If the application reads an API key from a request header and then includes that value in downstream outbound headers (e.g., when calling another service) or echoes it into response headers without strict allowlisting, an attacker can inject arbitrary header lines.

This becomes a web security issue when the injected header influences behavior beyond the intended scope. For example, an attacker might supply a newline and additional header fields such as X-Original-URL: or Set-Cookie: in an API key value. If FeathersJS or an intermediary layer forwards the key into an HTTP client call and appends it naively to the outbound header block, the injected newline can cause the client to send multiple headers. This may lead to cache poisoning, request smuggling, or authentication bypass depending on how downstream services interpret the duplicated or manipulated headers.

In a black-box scan, middleBrick tests this by sending crafted API key values containing header-like sequences (e.g., \r\nX-Injected: 1) and observing whether the response contains those injected lines. The framework itself does not introduce the injection; the risk arises from custom code that uses the API key in header construction without canonicalization. Real examples include concatenating the API key directly into outbound headers or using it in routing decisions that influence which headers are sent. Since API keys often appear in logs and metrics, injected headers that contain sensitive data can also contribute to data exposure when logs are not adequately protected.

middleBrick’s LLM/AI Security checks do not directly test header injection, but the broader scan includes Data Exposure and Input Validation checks that can flag unsafe reflection of API keys into outputs or headers. When scanning an API endpoint that uses API keys, middleBrick runs multiple security checks in parallel, including Authentication, Input Validation, and Data Exposure, to identify whether header manipulation is possible through request surfaces that accept or echo API key values.

To remediate header injection with API keys in FeathersJS, ensure API key values are never used to construct HTTP headers directly. Treat API keys as opaque credentials and avoid echoing them into any header, response, or log field that could be influenced by an attacker. Use strict allowlisting when you must propagate keys to downstream services, and prefer built-in authentication providers where possible.

Example of unsafe code that concatenates an API key into outbound headers:

// UNSAFE: using API key directly in outbound headers
app.hooks.after.push(async context => {
  const apiKey = context.params.headers['x-api-key'];
  if (apiKey) {
    context.axiosConfig.headers['X-API-Key'] = apiKey; // reflects attacker-controlled value
  }
  return context;
});

Safer approach: validate and normalize the key, and do not forward raw user input as headers. Instead, use a fixed header name with a server-side secret or token that is not derived from user input:

// SAFER: do not reflect API key in outbound headers
const ALLOWED_KEYS = new Set(['abc123', 'def456']); // server-side list or hashed lookup
app.hooks.after.push(async context => {
  const apiKey = context.params.headers['x-api-key'];
  if (!ALLOWED_KEYS.has(apiKey)) {
    throw new Error('Unauthorized');
  }
  // Use a fixed header for downstream calls, not the raw API key
  context.axiosConfig.headers['X-Internal-Token'] = process.env.INTERNAL_TOKEN;
  return context;
});

If you must forward credentials to another service, use environment variables or a secrets manager to obtain a separate token, and ensure the value is not derived from or concatenated with user input. Additionally, enforce input validation to reject newlines and control characters in API key formats:

// Validate API key format to prevent header injection
const validateApiKey = key => /^[A-Za-z0-9\-_]+$/.test(key);
app.hooks.before.push(async context => {
  const apiKey = context.params.headers['x-api-key'];
  if (!apiKey || !validateApiKey(apiKey)) {
    throw new Error('Invalid API key');
  }
  return context;
});

For production, combine these practices with framework-level security settings, transport encryption, and robust logging that redacts sensitive values. middleBrick’s CLI can be used to verify that your endpoints no longer reflect API keys in headers by scanning the service and reviewing the findings in JSON or text output.

Use the GitHub Action to add API security checks to your CI/CD pipeline and fail builds if risky patterns are detected. The MCP Server enables scanning APIs directly from your AI coding assistant within the IDE, helping you catch header injection and other issues early during development.