Crlf Injection in Rails with Api Keys

Crlf Injection occurs when an attacker can inject a carriage return (CR, \r) and line feed (\n) sequence into a header or status line. In Rails, this often arises when user-controlled data is reflected in HTTP headers, such as custom API key headers used for authentication. If an API key value is taken directly from request parameters or headers and then echoed into downstream outbound requests or logs without sanitization, an attacker can supply a key containing \r\n to split the header line and inject new headers or status lines.

Consider a Rails service that forwards requests to a downstream API using an API key supplied by the client:

def proxy
  api_key = params[:api_key]
  uri = URI('https://api.external.example.com/resource')
  request = Net::HTTP::Get.new(uri)
  request['X-API-Key'] = api_key
  response = Net::HTTP.start(uri.hostname, uri.port, use_ssl: true) { |http| http.request(request) }
  render plain: response.body
end

If the client sends api_key as valid_key\r\nX-Header: injected, the header line splits and an additional header X-Header: injected is injected into the outbound request. This can lead to request smuggling, header manipulation, or unintended authorization bypass if the injected header affects behavior (e.g., Authorization or Host). In logging, a newline in the API key can fragment log lines, making it harder to detect anomalies and potentially enabling log injection that obscures attacker activity.

The same risk applies when API keys are used in custom headers for outbound calls to third-party services. If the key is stored in a configuration or database and later interpolated into a header without validation, a compromised key containing CRLF can poison the output stream. In Rails, common helpers like redirect_to or render also use headers (e.g., Location); injecting CRLF via a key reflected in a header can facilitate open redirects or response splitting.

Because middleBrick tests unauthenticated attack surfaces, it can detect places where API key inputs reach headers or status lines without canonicalization. Findings typically highlight missing input validation and provide remediation guidance to ensure keys are treated as opaque strings and never interpreted as delimiters.

To prevent Crlf Injection when handling API keys in Rails, ensure that keys are validated, sanitized, and never directly interpolated into headers or status lines. Treat API keys as opaque strings and avoid any transformation that could introduce control characters.

1) Validate and sanitize input

Reject or sanitize API keys containing carriage returns or line feeds before use. A simple validation can strip or reject such characters:

class ApiKeyValidator < ActiveModel::Validator
  def validate(record)
    if record.api_key&.include?("\r") || record.api_key&.include?("\n")
      record.errors[:api_key] << 'must not contain CR or LF characters'
    end
  end
end

class ApiKey < ApplicationRecord
  validates_with ApiKeyValidator
end

2) Use a safe method to set headers

When passing an API key to an outbound request, set it via a method that does not interpret newline characters. Prefer assigning the key as a string to the header key directly, and avoid manual concatenation. Rails' Net::HTTP header assignment already enforces one header-value pair per key, but ensure the value is clean:

def safe_proxy
  api_key = params[:api_key].to_s.strip.delete("\r\n")
  uri = URI('https://api.external.example.com/resource')
  request = Net::HTTP::Get.new(uri)
  request['X-API-Key'] = api_key
  response = Net::HTTP.start(uri.hostname, uri.port, use_ssl: true) { |http| http.request(request) }
  render plain: response.body
end

3) Enforce strict parameter filtering in logs

Configure Rails to avoid logging raw API keys or filter sensitive parameters to reduce exposure risk. In config/initializers/filter_parameter_logging.rb:

Rails.application.config.filter_parameters += [:api_key, :'X-API-Key']

This prevents newline-containing keys from corrupting log lines and aids in detecting injection attempts through log anomalies.

4) Use environment variables or secure vaults for keys

Instead of accepting API keys from clients, store them securely on the server and reference them by an identifier. For example, use Rails credentials or an environment variable and map identifiers to keys internally:

API_KEYS = Rails.application.credentials.api_keys # { client_a: 's3cr3t' }

def authorized?
  key_id = params[:key_id]
  provided_key = request.headers['HTTP_X_API_KEY']
  ActiveSupport::SecurityUtils.secure_compare(provided_key, API_KEYS[key_id])
end

By decoupling the identifier from the raw key and using constant-time comparison, you reduce the risk of injection and accidental exposure.

For comprehensive scanning, use the middleBrick CLI to validate these patterns in your endpoints: middlebrick scan <url>. Teams on the Pro plan can enable continuous monitoring so changes to header handling are flagged automatically, and the GitHub Action can fail builds if risk scores degrade.