Crlf Injection in Loopback with Mutual Tls

Crlf Injection occurs when an attacker can inject CRLF characters (\r\n) into a header or the status line of an HTTP message. In Loopback applications that use Mutual Tls (mTLS), the presence of mTLS can change how injected headers are interpreted and how responses are routed, which can amplify the impact in specific configurations.

With mTLS, the server validates the client certificate before application logic runs. If the application uses the client certificate information to route requests, select backends, or decide authorization, an attacker who can control request headers (for example via a proxy or an insecure upstream) may inject \r\n to create an extra blank line. This can cause the recipient to treat injected content as a new header or as the start of a second request. In a Loopback service that chains calls to internal APIs using the client certificate for identity, a single injected \r\nHost: can lead the outbound request to a different host than intended, effectively bypassing intended routing logic.

Another scenario involves response splitting. If a Loopback endpoint reflects a header value (such as X-Client-Common-Name from the mTLS certificate) without sanitization, an attacker can supply \r\nSet-Cookie: malicious=1. Even though the TLS channel remains encrypted, the injected header is processed by the HTTP layer before application code, potentially causing the response to be interpreted differently by downstream proxies or browsers that share the same certificate context. Because mTLS ties identity to the certificate, applications may mistakenly trust header values derived from the certificate and fail to sanitize reflected data, making the injection more likely to succeed in multi-hop or API-gateway setups where Loopback services are chained.

Consider a Loopback connector that forwards requests to another service using the client certificate for authentication. If an attacker controls a header like X-Forwarded-For and injects \r\nAuthorization: Bearer attacker_token, the forwarded request may carry the malicious authorization header. The server’s mTLS verification still passes, but the injected header changes the authorization context. This demonstrates how mTLS does not prevent header injection; it only ensures the identity of the peer, while the application must still validate and encode header values.

To detect this pattern, scans check whether user-controlled input is reflected in headers without proper filtering and whether the application uses certificate metadata in a way that could be overridden by injected CRLF. The LLM/AI Security checks included in middleBrick also probe for prompt injection and output leakage, which are separate from Crlf Injection but highlight how uncontrolled inputs can lead to unintended behavior in any API, including those secured with mTLS.

middleBrick scans such endpoints as part of its 12 parallel checks, including Input Validation and Property Authorization, and reports findings with severity and remediation guidance. By correlating OpenAPI/Swagger specs (with full $ref resolution) against runtime behavior, the scanner identifies places where header values derived from certificates or client data may lead to injection without sanitization.

Remediation focuses on strict input validation, safe header handling, and avoiding the use of client-supplied data to construct headers or routing decisions. Below are concrete code examples for a Loopback application using mTLS.

First, ensure your server enforces mTLS and extracts certificate information safely without relying on headers that can be influenced by the client.

const https = require('https');
const fs = require('fs');
const express = require('express');
const app = express();

const serverOptions = {
  key: fs.readFileSync('server-key.pem'),
  cert: fs.readFileSync('server-cert.pem'),
  ca: fs.readFileSync('ca-cert.pem'),
  requestCert: true,
  rejectUnauthorized: true,
};

https.createServer(serverOptions, app).listen(3000, () => {
  console.log('mTLS server running on port 3000');
});

In your routes, avoid using raw header values that may contain CRLF. Instead, validate and encode them. For example, if you need to log a certificate field, sanitize it explicitly.

const sanitizeHeader = (value) => {
  if (typeof value !== 'string') return '';
  return value.replace(/[\r\n]/g, '');
};

app.get('/profile', (req, res) => {
  const raw = req.socket.getPeerCertificate();
  const commonName = sanitizeHeader(raw.subject?.CN || '');
  // Use commonName safely; do not reflect it into headers without encoding
  res.json({ commonName });
});

When forwarding requests to other services, do not forward headers derived from client input without strict allowlisting. Use a hardcoded set of safe headers and explicitly drop any headers that could contain CRLF.

const allowedHeaders = new Set(['content-type', 'x-request-id']);

function filterHeaders(source) {
  const target = {};
  for (const [key, value] of Object.entries(source)) {
    const lower = key.toLowerCase();
    if (allowedHeaders.has(lower) && typeof value === 'string' && !/\r/.test(value) && !/\n/.test(value)) {
      target[key] = value;
    }
  }
  return target;
}

app.use('/api', (req, res) => {
  const headers = filterHeaders(req.headers);
  // proceed with trusted headers only
});

If you use Loopback connectors that rely on certificate metadata for routing, validate the certificate fields against an allowlist and never construct URLs or headers by concatenating raw certificate values. This prevents CRLF injection attempts that aim to manipulate routing or authorization in chained services.

middleBrick’s CLI can be used to scan your Loopback endpoints from the terminal:

middlebrick scan https://api.example.com

For teams integrating security into development workflows, the GitHub Action adds API security checks to CI/CD pipelines, failing builds if risk scores drop below your configured threshold. The Pro plan supports continuous monitoring and can alert on regressions across multiple environments.