Crlf Injection in Laravel with Api Keys

Crlf Injection occurs when user-controlled data is inserted into HTTP headers without proper sanitization, allowing an attacker to inject Carriage Return (CR, \r) and Line Feed (\n) sequences. In Laravel applications that expose API keys via response headers, this becomes particularly dangerous. If an API key is dynamically set in a header such as X-API-Key, and the key or a related value is derived from unvalidated user input, an attacker can terminate the header line early and inject additional headers or content.

Consider a Laravel route that echoes an API key into a custom header based on a request parameter:

// Risky example: directly using user input in a header
Route::get('/resource', function (Illuminate\Http\Request $request) {
    $apiKey = $request->query('key');
    header('X-API-Key: ' . $apiKey);
    return response('OK');
});

If the key query parameter contains CRLF sequences (e.g., abc%0D%0AX-Frame-Options:%20DENY), the injected header will be interpreted by some HTTP clients or intermediaries, potentially leading to HTTP response splitting, cache poisoning, or header manipulation. Even when using Laravel’s helper header() or the response()->withHeader() methods, unsanitized input can bypass developer expectations because these helpers do not inherently validate or neutralize CR/LF characters.

When API keys are involved, Crlf Injection can expose more than just header manipulation. An attacker may inject malicious headers that affect downstream systems, such as authentication proxies or API gateways that process the key. In scenarios where API keys are logged or inspected, injected headers can alter log formatting, obscure the true origin of requests, or facilitate further attacks like request smuggling. Because API keys often carry elevated privileges, ensuring their integrity and isolation from header parsing logic is critical to maintaining trust boundaries.

Another subtle vector involves setting multiple headers via arrays in Laravel responses. For example:

$response = response('OK');
$response->headers->set('X-API-Key', $request->input('key'));
return $response;

Even when using structured methods, if the input is not sanitized, CRLF characters can still be injected, causing malformed headers or enabling injection into subsequent header lines. Laravel does not automatically sanitize header values for control characters, so developers must treat any user-supplied data destined for headers as potentially hostile.

To prevent Crlf Injection when handling API keys in Laravel, you must ensure that any user-controlled data used in headers is stripped of CR and LF characters. The safest approach is to reject or sanitize input rather than attempting to clean it, because header keys and values have strict formatting rules.

1. Reject input containing CRLF characters

Validate the API key before using it in headers by explicitly checking for carriage return and line feed characters:

Route::get('/resource', function (Illuminate\Http\Request $request) {
    $apiKey = $request->query('key');
    if (preg_match('/[\r\n]/', $apiKey)) {
        return response('Invalid API key', 400);
    }
    header('X-API-Key: ' . $apiKey);
    return response('OK');
});

This approach ensures that malicious sequences cannot be smuggled into headers under any circumstances.

2. Use Laravel’s response builder with strict header handling

Prefer Laravel’s response methods and explicitly set headers using normalized strings. Avoid directly interpolating raw input into header lines:

$apiKey = $request->query('key');
if (preg_match('/[\r\n]/', $apiKey)) {
    return response('Invalid API key', 400);
}
return response('OK')
    ->withHeader('X-API-Key', $apiKey);
}

Using withHeader() after validation ensures consistent formatting and leverages Laravel’s internal handling of headers.

3. Avoid using user input as header keys

Never allow user input to dictate header names. Header keys should be hardcoded or selected from a strict allowlist:

// Good: header name is fixed, only value is dynamic
$apiKey = $request->query('key');
if (preg_match('/[\r\n]/', $apiKey)) {
    return response('Invalid API key', 400);
}
return response('OK')
    ->header('X-API-Key', $apiKey);

This eliminates the risk of header injection through key manipulation entirely.

4. Centralize header logic in middleware

For applications managing API keys at scale, implement a middleware layer that validates and sets headers consistently:

class ValidateApiKeyHeader
{
    public function handle($request, Closure $next)
    {
        $apiKey = $request->query('key');
        if ($apiKey && preg_match('/[\r\n]/', $apiKey)) {
            return response('Invalid API key', 400);
        }
        if ($apiKey) {
            header('X-API-Key: ' . $apiKey);
        }
        return $next($request);
    }
}

Register this middleware in your route or globally to enforce uniform protection across endpoints that expose API keys.

These measures ensure that API keys remain isolated from header parsing logic and cannot be used to manipulate HTTP message structure through CRLF Injection.