Cache Poisoning in Sinatra with Bearer Tokens

Cache poisoning occurs when an attacker manipulates cached responses so that malicious or incorrect data is served to other users. In Sinatra applications that use Bearer token authentication, a common misconfiguration can cause authenticated responses to be cached and then replayed to different users, effectively leaking private data or allowing unauthorized access.

When a Sinatra route uses a Bearer token in the Authorization header to gate access, the application may still generate a successful response that includes sensitive data. If the caching layer (e.g., a reverse proxy or CDN) does not include the Authorization header as part of the cache key, responses for one authenticated user can be served to another authenticated user with a different token. This happens because the cache treats the URL and query parameters as the cache key, ignoring the Authorization header by default.

For example, consider a Sinatra endpoint that returns user profile information based on a Bearer token. An authenticated request with token A might return profile data for user A and get cached. A subsequent request with token B to the same URL could receive the cached response containing user A’s data, leading to a broken access control issue and potential data exposure. This becomes more critical when the response includes PII, account details, or access-controlled resources.

Additional risk arises if the application caches error responses differently based on token validity. An attacker could probe endpoints with invalid tokens and observe whether distinct error messages are cached and reused, potentially leaking information about valid versus invalid tokens. In environments where OpenAPI specifications are used to document endpoints, such caching behavior might inadvertently expose operation IDs or parameter details that should remain internal.

To identify this class of issue during a scan, middleBrick performs unauthenticated checks that analyze whether responses vary correctly based on Authorization headers and whether caching headers like Cache-Control and Vary are set appropriately. The tool also cross-references any provided OpenAPI/Swagger spec to ensure documented authentication schemes align with runtime behavior, reducing the chance of overlooked misconfigurations.

To prevent cache poisoning when using Bearer tokens in Sinatra, you must ensure that cached responses are segregated by the Authorization header or that authenticated responses are marked as non-cacheable. Below are specific, actionable fixes with realistic code examples.

1. Use the Vary Header to Tie Cache Keys to Authorization

Configure your reverse proxy or CDN to include the Authorization header in the cache key. In Sinatra, you can instruct caches to vary by the Authorization header using the Vary response header:

require 'sinatra'

before do
  # Ensure caches differentiate responses per token
  headers 'Vary' => 'Authorization'
end

get '/profile' do
  token = request.env['HTTP_AUTHORIZATION']&.to_s.gsub('Bearer ', '')
  halt 401, { error: 'Unauthorized' }.to_json unless valid_token?(token)
  user_data = fetch_user_data(token)
  content_type :json
  user_data.to_json
end

def valid_token?(token)
  # Replace with actual token validation logic
  %w[tokenA tokenB].include?(token)
end

def fetch_user_data(token)
  # Dummy data; in practice, fetch from a data store
  { 'user' => token, 'email' => "#{token}@example.com" }
end

This tells shared caches to store separate copies for each unique Authorization header value, preventing token A’s response from being served to token B.

2. Disable Caching for Authenticated Responses

If per-token caching is not feasible, explicitly disable caching for authenticated endpoints by setting no-store or no-cache headers:

require 'sinatra'

before '/secure/*' do
  headers 'Cache-Control' => 'no-store, no-cache, must-revalidate, private',
          'Pragma' => 'no-cache',
          'Expires' => '0'
end

get '/secure/account' do
  token = request.env['HTTP_AUTHORIZATION']&s;to_s.gsub('Bearer ', '')
  halt 401, { error: 'Unauthorized' }.to_json unless valid_token?(token)
  content_type :json
  { account: 'sensitive_data' }.to_json
end

This approach ensures that authenticated responses are not stored and are always fetched fresh, mitigating the risk of token-bound data being cached incorrectly.

3. Validate and Normalize Authorization Input

Ensure that Bearer token parsing is consistent and does not introduce ambiguity that could affect cache behavior. Avoid including extra whitespace or accepting multiple Authorization headers:

require 'sinatra'

helpers do
  def current_token
    auth = request.env['HTTP_AUTHORIZATION']
    return nil unless auth&.start_with?('Bearer ')
    auth.split(' ').last
  end
end

before do
  halt 400, { error: 'Bad Request' }.to_json unless current_token
end

Consistent parsing reduces edge cases where malformed or ambiguous headers lead to unexpected caching behavior.

For larger API portfolios, middleBrick’s CLI can be used to scan Sinatra-based services and validate whether appropriate Vary and Cache-Control headers are present. Teams on the Pro plan can enable continuous monitoring to detect regressions in caching behavior automatically, and the GitHub Action can fail builds if insecure defaults are introduced.