Cache Poisoning in Sinatra with Basic Auth

Cache poisoning occurs when an attacker causes a cache to store malicious content that is then served to other users. In Sinatra applications that use HTTP Basic Authentication, a common misconfiguration can cause authenticated responses to be cached and later served to unauthenticated users, effectively bypassing access controls. This typically happens when caching logic does not differentiate between authenticated and unauthenticated requests, or when shared caches (e.g., reverse proxies or CDNs) are used without proper cache-key normalization.

Consider a Sinatra route that returns sensitive user data and relies on Basic Auth for access control:

require 'sinatra'
require 'base64'

configure do
  set :bind, '0.0.0.0'
end

before do
  auth = request.env['HTTP_AUTHORIZATION']
  unless auth&.start_with?('Basic ')
    halt 401, { 'WWW-Authenticate' => 'Basic realm="Restricted"' }.to_json
  end
  decoded = Base64.strict_decode64(auth.split(' ', 2).last)
  username, password = decoded.split(':', 2)
  unless username == 'admin' && password == 'secret'
    halt 401, { error: 'Unauthorized' }.to_json
  end
end

get '/account' do
  content_type :json
  { account_number: '987654321', ssn: '123-45-6789' }.to_json
end

If a shared cache (or browser cache) is configured to cache GET /account based only on the request path and method, and does not include the Authorization header in the cache key, an authenticated user’s sensitive response might be stored. A subsequent unauthenticated request for /account could then receive the cached, authenticated response, exposing private data. This is a cache poisoning vector because the cache is unintentionally serving privileged information to users who did not authenticate.

The risk is amplified when responses include vary headers that do not account for authentication context, or when caching is applied at the infrastructure layer without awareness of application-level access controls. An attacker might probe endpoints with malformed or missing Authorization headers to observe whether cached responses are returned, effectively conducting a cache-based information disclosure.

Because middleBrick tests unauthenticated attack surfaces, it can surface such misconfigurations by detecting endpoints that return sensitive data without enforcing authentication on every request and by analyzing cache-related headers. Findings include details on missing Vary usage and recommendations to scope caching to authenticated contexts only.

To prevent cache poisoning when using Basic Auth in Sinatra, ensure that authenticated responses are never cached for unauthenticated users and that caching explicitly accounts for authentication state. The primary defenses are to avoid caching responses that require authentication, to use the Vary header correctly, and to enforce authentication on every request.

1. Do not cache authenticated responses

The safest approach is to instruct caches not to store responses that require authentication. Add appropriate cache-control headers to sensitive routes:

get '/account' do
  content_type :json
  headers 'Cache-Control' => 'no-store, no-cache, must-revalidate, private'
  { account_number: '987654321', ssn: '123-45-6789' }.to_json
end

Using private ensures that the response may be stored by the browser but not by shared caches; no-store prevents storage entirely. This directly mitigates the risk of cached sensitive data being served to unauthorized users.

2. Use Vary to differentiate by Authorization header

If you must allow caching for performance, use the Vary header to ensure caches store separate versions based on the presence and value of the Authorization header:

before do
  auth = request.env['HTTP_AUTHORIZATION']
  # existing auth checks…
  cache_control :public, :must_revalidate
  if auth&.start_with?('Basic ')
    response['Vary'] = 'Authorization'
  else
    response['Vary'] = 'Authorization, Accept-Encoding'
  end
end

get '/public-data' do
  content_type :json
  { public: true, message: 'safe to cache' }.to_json
end

Note that for endpoints that require authentication, do not add public and avoid caching altogether. The example above shows how to safely vary on Authorization for endpoints that may be publicly cacheable under other conditions.

3. Enforce authentication on every request and avoid default or missing credentials

Ensure each route validates credentials and does not rely on a before filter that might be accidentally bypassed. Explicit checks prevent scenarios where missing or malformed headers are treated as valid defaults:

helpers do
  def authenticate!
    auth = request.env['HTTP_AUTHORIZATION']
    halt 401, { error: 'Unauthorized' }.to_json unless auth&.start_with?('Basic ')
    decoded = Base64.strict_decode64(auth.split(' ', 2).last)
    username, password = decoded.split(':', 2)
    halt 401, { error: 'Unauthorized' }.to_json unless username == 'admin' && password == 'secret'
  end
end

get '/secure' do
  authenticate!
  content_type :json
  { secret: 'only for authenticated requests' }.to_json
end

Always prefer environment-aware authentication checks rather than assuming a before filter applies universally. When in doubt, prefer short-lived tokens or session-based mechanisms over Basic Auth for sensitive endpoints, but if Basic Auth is required, ensure credentials are never transmitted over unencrypted channels and are validated on every request.

middleBrick can support remediation verification by rescanning endpoints after changes and confirming that sensitive routes include no-store or appropriate Vary headers and that unauthenticated access does not return sensitive data.