Crlf Injection in Sails with Bearer Tokens

Crlf Injection occurs when an attacker can inject carriage return (CR, \r) and line feed (\n) characters into a header or status-line context. In Sails.js, this often arises when dynamic data—such as tokens or user-controlled strings—flows into functions that construct HTTP headers or status codes without proper sanitization. When Bearer Tokens are handled in Sails, the risk emerges if a token value or a token-derived header is concatenated into a response header or status line without validation. For example, if a controller takes a token from a request header (e.g., Authorization: Bearer <token>), re-encodes it, and then sets it into another header such as X-API-Token, unsanitized newline characters in the token can split the header stream and inject additional headers or response lines. This can enable HTTP response splitting, header manipulation, or cache poisoning. Sails applications that build custom authentication flows, such as token introspection endpoints or proxy-style middleware, are particularly susceptible if they reflect token data into headers. Because Bearer Tokens often contain characters that are safe in a JSON body but dangerous in a header context, the combination increases the likelihood of unintended line breaks if input validation is limited to presence checks rather than strict character and format checks. Attack patterns like response splitting can lead to XSS in certain browser configurations or to cache poisoning, and may complicate logging and monitoring by injecting malicious content into backend logs. The vulnerability is not inherent to Bearer Tokens themselves but to how Sails code handles and reuses token strings in header construction. Developers should treat any token that influences headers as potentially malformed and apply strict allow-lists (e.g., base64url characters only) and canonicalization before use.

Remediation in Sails focuses on two areas: strict validation of token characters and safe header-setting practices. First, enforce a strict character allow-list for Bearer Tokens used in header contexts. A typical Bearer Token contains only alphanumeric characters, hyphens, underscores, dots, and plus signs; reject any token containing CR, LF, or other control characters. Second, avoid using dynamic token strings directly in header-setting functions; instead, use Sails’ built-in mechanisms for header management and ensure you never write raw concatenated header values. Below are examples of risky and safe patterns.

Risky pattern: reflecting a Bearer Token into a custom header

// UNSAFE: directly using token in header construction
const token = req.headers.authorization?.replace('Bearer ', '');
if (token) {
  res.set('X-Bearer-Token', token); // Vulnerable to CRLF injection
  return res.ok();
}

Safe pattern: validate and sanitize before use

// SAFE: strict validation and canonical header setting
const auth = req.headers.authorization || '';
const match = auth.match(/^Bearer ([A-Za-z0-9\-._+]+)$/);
if (!match) {
  return res.badRequest('Invalid authorization format');
}
const token = match[1];
// Use Sails response methods that do not allow header injection
res.set('X-Bearer-Token', token);
return res.ok();

For APIs that forward tokens to upstream services, do not concatenate tokens into header strings via interpolation. Instead, use a library that handles header objects safely, or rely on Sails’ response object to manage headers. Additionally, implement logging that redacts or hashes token values to avoid exposing sensitive data in logs. When integrating with third-party identity providers, validate token structure against expected patterns and reject tokens with unexpected characters. These steps reduce the attack surface for CRLF Injection while maintaining compatibility with standard Bearer Token formats. Security findings from scans can highlight endpoints where token data reaches headers, enabling targeted fixes aligned with OWASP API Security Top 10 and compliance mappings available in reports generated through middleBrick scans, the CLI (middlebrick scan <url>), or the GitHub Action for CI/CD gates.