Crlf Injection in Laravel with Jwt Tokens

Crlf Injection occurs when an attacker can inject a carriage return (CR, \r) and line feed (LF, \n) sequence into a header or cookie value. In Laravel, JWT tokens are often stored in cookies or passed via Authorization headers. If user-controlled input is used to build cookie values or header-like data without proper sanitization, and the resulting string is passed to functions that interpret headers, the injected CRLF can split the output stream. This can lead to header manipulation or response splitting, even when the token itself is signed. For example, if a Laravel application embeds a JWT in a Set-Cookie header and does not validate or encode newlines in a claim or parameter, an attacker can inject \r\n into the claim value, causing the server to append additional headers such as Set-Cookie or Content-Type. Because JWTs are frequently handled by middleware that reads headers and cookies, the injection may not be immediately visible in token validation logic but can affect downstream processing and logging.

In a black-box scan, middleBrick tests for CRLF injection across headers, cookies, and URL paths. When JWT tokens are transmitted via cookies or custom headers, the scanner probes for \r\n injection points and examines whether injected content appears in subsequent headers or responses. This is relevant in unauthenticated attack surface testing because attackers can often influence cookie values or header-like parameters without authentication. The presence of JWTs does not prevent header manipulation if input validation is missing; the token’s signature protects integrity but not the surrounding protocol handling. middleBrick’s checks include verifying that inputs embedded in headers or cookies are properly restricted and that newline characters are rejected or encoded.

An example of unsafe behavior in Laravel might involve directly using request input in cookie creation without sanitization:

// UNSAFE: user input used in cookie value without sanitization
$value = request('data');
return response()->cookie('jwt_ref', $value, 60);

If $value contains abc\r\nSet-Cookie: foo=bar, the resulting header stream can be split, causing the client to accept an additional cookie. Even if the value is later used in an Authorization header, similar risks exist if the application concatenates user data into header-like strings.

To prevent CRLF Injection when handling JWTs in Laravel, ensure that any user-controlled data used in headers, cookies, or token claims is strictly validated and sanitized. Do not rely on the JWT signature to protect surrounding protocol handling; treat headers and cookies as separate security boundaries. Use Laravel’s built-in response helpers and avoid manually constructing header strings with unescaped input.

Below are concrete, safe patterns for working with JWTs and cookies in Laravel.

• Set cookies using Laravel’s response builders, which handle encoding appropriately:

use Illuminate\Http\Response;

$token = 'your.jwt.token.here';
return response()->json(['data' => 'ok'])
    ->cookie('jwt_ref', $token, 60, null, null, false, true, false, Response::SAME_SITE_LAX);

• Validate and sanitize input before using it in any header or cookie context. Reject or encode newline characters:

$input = request('data');
if (preg_match('/[\r\n]/', $input)) {
    return response('Invalid input', 400);
}
return response()->cookie('safe_ref', $input, 60, null, null, false, true, false, Response::SAME_SITE_LAX);

• When building Authorization headers dynamically, avoid concatenation with user input. If you must include dynamic values, explicitly whitelist allowed characters and avoid any CRLF characters:

$prefix = 'Bearer';
$token = 'your.jwt.token.here';
// Only use trusted, pre-validated tokens; do not append user input.
$headers = [
    'Authorization' => $prefix . ' ' . $token,
];
return $headers;

• For JWT claims that may be reflected in headers or logs, enforce strict character policies and avoid storing raw user input in claims that affect protocol handling. Use framework middleware to validate incoming tokens and claims rather than constructing header values from raw input.

middleBrick’s scans can validate that your endpoints do not reflect newline characters in headers or cookies and that inputs are properly constrained. By combining these code patterns with continuous monitoring via the middleBrick Dashboard or the CLI tool, you can detect regressions early. The GitHub Action can enforce a minimum security score before deployment, and the MCP Server allows you to run scans directly from your IDE while developing JWT-related functionality.