Api Key Exposure in Sinatra with Api Keys

Sinatra is a lightweight Ruby web framework that encourages rapid development. When developers store and use API keys directly in application code or in easily accessible configuration files, they create an exposure surface that middleBrick detects as part of its Data Exposure and Property Authorization checks. An API key embedded in source files, initializer files, or environment-loaded strings can be inadvertently exposed through version control, logs, or error pages.

In a Sinatra application, it is common to see API keys read from environment variables or hardcoded for convenience, for example:

require 'sinatra'

# Risky: API key hardcoded
API_KEY = 'sk_live_abc123def456'

get '/external' do
  headers 'Authorization' => "Bearer #{API_KEY}"
  # forward request to external service
end

If the repository is public or improperly access-controlled, this hardcoded key becomes a discoverable credential. middleBrick tests unauthenticated endpoints and checks for references to secrets in responses, headers, or error messages. A key exposed in client-side JavaScript, logs, or stack traces is flagged under Data Exposure with high severity because it can be used by unauthorized parties to call third-party services or access protected resources.

Another common pattern is loading keys via ENV without validation:

require 'sinatra'

api_key = ENV['EXTERNAL_API_KEY']

get '/data' do
  # Missing checks: is api_key present and valid?
  headers 'Authorization' => "Bearer #{api_key}"
  # ...
end

While using environment variables is safer than hardcoding, middleBrick identifies that missing runtime validation and authorization around the use of the key can lead to BOLA/IDOR and Property Authorization issues if the key is tied to user-specific permissions. An attacker may manipulate requests to substitute or omit the key, and without proper checks the application may forward requests with an invalid or missing key, exposing behavior that reveals whether keys are present and how they are used.

SSRF findings can also intersect with API key exposure. If an endpoint accepts a URL and forwards it with an API key in headers, an attacker can force the server to make internal requests to metadata services where keys are often exposed:

require 'sinatra'
require 'net/http'

post '/fetch' do
  uri = URI(params[:url])
  key = ENV['INTEGRATION_KEY']
  response = Net::HTTP.get(uri, { 'Authorization' => "Bearer #{key}" })
  response
end

middleBrick flags this as both SSRF and Data Exposure if the key is consistently present in outbound headers and the endpoint is unauthenticated. The scan also checks whether API keys appear in responses, logs, or error messages, which would constitute insecure data handling.

Remediation centers on ensuring API keys are never hardcoded, are validated before use, and are not inadvertently exposed in responses or logs. middleBrick highlights these issues in its findings and provides guidance aligned with secure coding practices.

1) Use environment variables and never commit keys to source control:

require 'sinatra'

api_key = ENV['INTEGRATION_KEY']

before do
  halt 401, 'Missing API key' unless api_key && !api_key.strip.empty?
end

This ensures the key is supplied externally and is non-empty. The before filter halts requests when the key is missing, preventing calls with invalid credentials.

2) Avoid exposing keys in responses and logs:

configure do
  set :show_exceptions, false
end

error do
  # Do not include key or internal details in error responses
  'An error occurred'
end

Disabling detailed exceptions prevents keys from leaking through error pages or logs. Ensure any custom logging excludes sensitive values.

3) Validate and scope key usage per request/consumer:

post '/invoke' do
  provided = params[:api_key]
  system_key = ENV['SYSTEM_API_KEY']
  halt 403 unless provided == system_key

  # Proceed with request using system_key server-side
  headers 'Authorization' => "Bearer #{system_key}"
  # ...
end

Rather than passing client-provided keys directly downstream, compare them to a server-side key and use the server-side key for outbound calls. This prevents privilege escalation and ensures Property Authorization checks are enforced.

4) Mitigate SSRF to protect key exposure:

require 'sinatra'
require 'net/http'
require 'uri'

helpers do
  def safe_uri?(input)
    uri = URI.parse(input)
    %w[http https].include?(uri.scheme) && !uri.host.to_s.match?(/(localhost|127\.0\.0\.1|\[::1\])/i)
  rescue URI::InvalidURIError
    false
  end
end

post '/fetch' do
  halt 400 unless safe_uri?(params[:url])
  uri = URI(params[:url])
  key = ENV['INTEGRATION_KEY']
  response = Net::HTTP.get(uri, { 'Authorization' => "Bearer #{key}" })
  response
end

Validate and restrict target hosts to prevent internal requests that could expose metadata or keys. Combined with key validation, this reduces the likelihood of key compromise via SSRF.

5) Rotate keys and monitor usage externally. While not a code change, remediation guidance from middleBrick recommends rotating exposed keys immediately and reviewing integration patterns to minimize broad permissions.