Api Key Exposure in Sinatra with Oauth2

Sinatra is a lightweight Ruby web framework often used to build OAuth2 authorization servers or resource servers. When OAuth2 is used improperly in Sinatra, API keys and bearer tokens can be unintentionally exposed through logs, error messages, or misconfigured endpoints. For example, if an endpoint accepts an API key as a query parameter and also uses OAuth2 bearer tokens, the combination can lead to sensitive credentials being logged or reflected in responses.

Consider a Sinatra route that accepts an API key while also validating an OAuth2 token:

require 'sinatra'
require 'json'

get '/v1/data' do
  api_key = params['api_key']
  authorization = request.env['HTTP_AUTHORIZATION']

  if authorization&&authorization.start_with?('Bearer ')
    token = authorization.split(' ').last
    # token validation logic here
    { api_key_received: api_key, token_valid: true }.to_json
  else
    status 401
    { error: 'missing_token' }.to_json
  end
end

If the client sends the API key in the URL (e.g., /v1/data?api_key=sk_live_xxx), that key may be captured in web server access logs, browser history, or network monitoring tools. Even when OAuth2 bearer tokens are used for authorization, leaking the API key in query strings creates a secondary exposure path. An attacker who gains access to logs or can perform network sniffing may recover the key and abuse associated resources.

OAuth2 scopes and redirect URIs can also contribute to exposure if not strictly validated. A misconfigured redirect URI may cause authorization codes or tokens to be sent to an attacker-controlled endpoint, indirectly exposing API-related credentials. Additionally, error messages in Sinatra that reveal stack traces or internal paths can disclose integration details that facilitate further attacks.

Middleware or logging configurations that record full request URLs—including query parameters—will inadvertently store API keys. This is especially risky when combined with OAuth2 flows where tokens and keys are both present. Without strict input handling and transport protections, the integration of OAuth2 with API key-based access increases the likelihood of credential leakage.

To reduce exposure risk, avoid passing API keys in query parameters. Use HTTP headers for sensitive values and enforce HTTPS for all traffic. When integrating OAuth2, keep tokens out of logs and ensure error handling does not reveal sensitive context.

Use the sinatra-contrib logger filter to redact sensitive parameters, and avoid logging the full request URL when query parameters contain keys. Below is a revised example that reads the API key from a header and validates an OAuth2 bearer token without exposing values in logs:

require 'sinatra'
require 'json'
require 'securerandom'

configure do
  set :logging, :middleware
end

before do
  # Redact sensitive info from default logs
  request.env['sinatra.error'] = nil
end

helpers do
  def log_filtered(path, filtered_params)
    # Custom logging that omits keys and tokens
    puts "[#{Time.now.utc.iso8601}] #{path} filtered_params=#{filtered_params}"
  end
end

get '/v1/data' do
  api_key = request.env['HTTP_X_API_KEY']
  authorization = request.env['HTTP_AUTHORIZATION']

  unless api_key
    status 400
    { error: 'api_key_missing' }.to_json and return
  end

  unless authorization&&authorization.start_with?('Bearer ')
    status 401
    { error: 'invalid_token' }.to_json and return
  end

  token = authorization.split(' ').last
  # Perform token validation with your OAuth2 provider
  valid = validate_oauth2_token(token)

  if valid
    log_filtered(request.path, { api_key_present: true, token_scope: 'read' })
    { data: 'protected_resource', scope: 'read' }.to_json
  else
    status 403
    { error: 'insufficient_scope' }.to_json
  end
end

def validate_oauth2_token(token)
  # Replace with actual validation against your OAuth2 introspection endpoint
  # Example stub: check signature, audience, expiry, and scope
  return token == SecureRandom.hex(16) # simplistic placeholder
end

For OAuth2 authorization code flows, ensure that the redirect URI is an exact match in your provider configuration and does not accept wildcard or open redirects. Use Proof Key for Code Exchange (PKCE) to protect public clients:

# Example PKCE parameters in a Sinatra authorization request helper
def build_authorization_url(client_id, redirect_uri, code_verifier, scope)
  code_challenge = Base64.urlsafe_encode64(Digest::SHA256.digest(code_verifier)).gsub(/=+$/, '')
  "https://auth.example.com/oauth/authorize?response_type=code&client_id=#{client_id}&redirect_uri=#{URI.encode_www_form_component(redirect_uri)}&scope=#{URI.encode_www_form_component(scope)}&code_challenge=#{code_challenge}&code_challenge_method=S256"
end

Rotate API keys regularly and bind them to specific OAuth2 scopes and audiences. Use environment variables or a secrets manager for keys instead of embedding them in code or logs. MiddleBrick can help detect exposed API keys and OAuth2 misconfigurations by scanning your endpoints and correlating spec definitions with runtime behavior, providing prioritized findings and remediation guidance without requiring agent installation or credentials.