Crlf Injection on Cloudflare

CRLF injection occurs when an attacker can inject a Carriage Return (CR, \r) and Line Feed (LF, \n) sequence into a header or status-line context, causing the server or downstream proxy to misinterpret where headers end and content begins. In Cloudflare environments, this typically surfaces in two scenarios: custom serverless functions (e.g., Cloudflare Workers) that construct responses or forward requests, and integrations where origin behavior is influenced by reflected values that eventually reach the client or another backend.

Within Cloudflare Workers, a common pattern is reading a request header and echoing it into a response header without sanitization. For example, if a Worker sets X-Next-Path using a query parameter, an attacker can supply ?next=/home%0D%0ASet-Cookie:%20session=evil. The CRLF sequence (%0D%0A) splits the injected line into a separate header, potentially adding or overriding cookies, introducing new headers, or breaking response parsing. This mirrors classic HTTP response splitting, but within Cloudflare’s edge runtime, the impact is limited to the Worker’s response; however, it can still manipulate downstream caches or clients that process the manipulated response.

Another Cloudflare-specific pattern arises when Workers use request metadata to construct URLs or redirect targets. If a Worker reads request.headers.get('Referer') and appends it to a redirect without validation, an attacker can inject %0D%0ALocation:%20https://evil.com. While Cloudflare’s native redirect rules are strict, custom Workers logic that builds responses dynamically can be tricked into emitting extra headers or status lines. Because Cloudflare proxies and edge caches may normalize or forward these responses, injected headers can affect caching behavior or be reflected to clients, enabling session fixation or phishing within the protected domain.

In origin configurations behind Cloudflare, misconfigured integrations (e.g., serverless platforms or legacy apps) may treat CRLF-injected values as safe if they arrive via a header that Cloudflare adds or rewrites. For instance, if Cloudflare adds CF-Connecting-IP or other trusted headers based on incoming data, and an origin blindly uses those values to build further messages, the CRLF sequence can propagate into backend logs or responses, leading to log injection or subtle header splitting. This is less common with Cloudflare’s managed proxies, which enforce strict header normalization, but remains possible when custom logic bypasses those safeguards.

Detecting CRLF injection in Cloudflare setups requires validating that no user-controlled input is directly reflected into headers or status lines, and that Cloudflare-specific features are not inadvertently used to propagate unsanitized values. Because Cloudflare Workers run at the edge, testing must include both the Worker’s runtime behavior and the final response observed through the Cloudflare proxy. A reliable approach is to send requests with encoded CRLF sequences in parameters and inspect the raw HTTP response for unexpected header lines or malformed status codes.

Using middleBrick, you can automatically test for CRLF injection patterns as part of its 12 security checks, which run in parallel and include Input Validation and Unsafe Consumption assessments. middleBrick submits encoded probes such as test%0D%0ASet-Cookie:%20injected=value across relevant input vectors (query parameters, headers, and body) and scans the response for signs of header splitting, such as an injected Set-Cookie line appearing as a separate header. Because middleBrick performs black-box scanning without credentials, it safely exercises the unauthenticated attack surface of your Cloudflare-hosted APIs and serverless endpoints, surfacing findings with severity and remediation guidance within 5–15 seconds.

To manually verify, use curl to inspect raw responses. For example, assume a Worker exposes a search endpoint that echoes a query parameter in a custom header:

curl -v "https://example.com/search?q=test%0D%0AX-Extra: injected" -H "Accept: text/html"

In the output, look for a line like > X-Extra: injected appearing as a distinct header. If you observe this, CRLF injection is present. middleBrick’s report will highlight this as a high-severity finding under Input Validation and provide a concise remediation path, such as sanitizing newlines and validating header-safe characters before use.

Remediation focuses on ensuring that any value used to construct HTTP messages—whether in Workers or origin logic—is sanitized before inclusion. In Cloudflare Workers, use strict validation libraries and avoid concatenating raw user input into headers or status lines. For header values, strip or encode CR and LF characters, and prefer allow-lists for known-safe values. When constructing redirects or forwarding requests, validate URLs using a robust URL parser and reject inputs containing CRLF sequences.

Example remediation in a Cloudflare Worker using JavaScript:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

function sanitizeHeader(value) {
  if (!value) return '';
  return value.replace(/[\r\n]+/g, '');
}

async function handleRequest(request) {
  const url = new URL(request.url);
  const userProvided = url.searchParams.get('next') || '';
  const safeNext = sanitizeHeader(userProvided);

  // Use safeNext only in contexts where it is strictly necessary and validated
  const headers = new Headers();
  if (safeNext) {
    headers.set('X-Redirect-To', safeNext);
  }
  return new Response('OK', { status: 200, headers });
}

For Cloudflare-managed redirects or rules, avoid embedding user input directly into rule conditions that might affect header generation. Instead, use Cloudflare’s built-in transformations with strict templates that do not allow raw input interpolation. If integrating with backend services, ensure that Cloudflare does not forward unsanitized headers that could be misinterpreted by origin applications.

middleBrick’s Pro plan supports continuous monitoring and can be integrated into CI/CD pipelines via its GitHub Action to fail builds if a security score drops below your chosen threshold. This helps catch regressions that might reintroduce CRLF injection after code changes. For teams requiring deeper compliance evidence, the dashboard provides per-finding mappings to frameworks such as OWASP API Top 10 and PCI-DSS, reinforcing secure development practices across the API lifecycle.