Crlf Injection in Koa with Api Keys

Crlf Injection occurs when user-controlled data is reflected in HTTP headers without sanitization, allowing an attacker to inject newline characters (CRLF = \r\n). In Koa, this commonly arises when API keys or other external values are used to construct custom headers, set cookies, or influence response fields. Because header values must not contain newlines, a payload such as X-API-Key: abc123\r\nSet-Cookie: session=hijacked can split the header stream and inject additional headers or cookies. This becomes especially risky when API keys are accepted via query parameters or request headers and then echoed into the response header layer.

Consider a Koa middleware that logs or echoes the API key into a custom response header for diagnostic purposes:

const Koa = require('koa');
const app = new Koa();

app.use(async (ctx, next) => {
  const apiKey = ctx.request.headers['x-api-key'] || ctx.query.api_key;
  if (apiKey) {
    ctx.set('X-API-Key-Echo', apiKey); // vulnerable if apiKey contains CRLF
  }
  await next();
});

app.use(ctx => {
  ctx.body = 'ok';
});

app.listen(3000);

If an attacker sends a request with x-api-key: abc123\r\nX-Content-Type-Options: nosniff, the header injection can cause the server to output two separate headers. The CRLF terminates the intended X-API-Key-Echo header and starts a new one, potentially bypassing security-related headers or enabling cache poisoning. In unauthenticated scanning contexts, middleBrick’s LLM/AI Security checks include active prompt injection tests and output scanning; while these focus on AI endpoints, the same principle applies where reflected or injected content can escape intended boundaries. The scanner tests whether crafted inputs appear unexpectedly in outputs, which maps to header injection risks like Crlf Injection.

Because API keys are often treated as opaque secrets, developers may assume they are safe to reflect. However, any user-influenced data that reaches headers must be validated. Without strict allowlists, an API key containing \r or \n — whether from accidental formatting or a deliberate attack — can compromise header integrity. This is a classic Injection (CWE-93) and falls under the broader OWASP API Top 10:2023 Broken Object Level Authorization and Improper Neutralization of Special Elements.

Remediation focuses on never reflecting raw user input in headers and enforcing strict validation for API key usage. The safest approach is to treat API keys as opaque identifiers for authentication (e.g., verifying against a store) and avoid echoing them back in responses. If you must include API key material in logs or headers, ensure it is sanitized.

1) Reject or sanitize newlines in API key handling

Before using any value in a header, strip or reject carriage return and line feed characters. Use a validation layer that enforces a token format (e.g., alphanumeric and limited symbols) and rejects any input containing \r or \n.

const Koa = require('koa');
const app = new Koa();

function containsCrlf(value) {
  return value.includes('\r') || value.includes('\n');
}

app.use(async (ctx, next) => {
  const apiKey = ctx.request.headers['x-api-key'] || ctx.query.api_key;
  if (apiKey) {
    if (containsCrlf(apiKey)) {
      ctx.status = 400;
      ctx.body = { error: 'Invalid API key format' };
      return;
    }
    // Only set header if you must; prefer storing a mapping server-side
    ctx.set('X-API-Key-Status', 'verified');
    // Do NOT echo raw apiKey
  }
  await next();
});

app.use(ctx => {
  ctx.body = 'ok';
});

app.listen(3000);

2) Use server-side mapping instead of reflection

Rather than echoing the API key, validate it against a database or cache and set minimal, safe headers. This eliminates any injection surface while still allowing you to track or authorize requests.

const Koa = require('koa');
const app = new Koa();

// Simulated key store
const validKeys = new Set(['abc123', 'def456']);

app.use(async (ctx, next) => {
  const apiKey = ctx.request.headers['x-api-key'] || ctx.query.api_key;
  if (apiKey) {
    if (validKeys.has(apiKey)) {
      // Perform authorization logic here
      ctx.state.userKey = apiKey; // store for downstream use
      ctx.set('X-API-Key-Status', 'valid');
    } else {
      ctx.status = 401;
      ctx.body = { error: 'Unauthorized' };
      return;
    }
  }
  await next();
});

app.use(ctx => {
  ctx.body = 'ok';
});

app.listen(3000);

3) Middleware ordering and secure defaults

Place validation early in the middleware stack and avoid adding user input to headers at any stage. If your application integrates with tools like the middleBrick CLI or GitHub Action, you can automate scans to detect header-injection patterns. The dashboard can help track historical findings, while the MCP Server allows scans from your IDE to catch issues before code reaches production.

Always prefer framework-supplied header setters (e.g., ctx.set) and ensure they receive already-sanitized values. Combine input validation with a robust authentication layer to reduce the impact of any residual misconfigurations.