Api Key Exposure in Rails with Basic Auth

Basic Authentication in Rails sends credentials in an Authorization header encoded as base64, not encrypted. Because base64 is easily reversible, any interceptor that captures the header can decode the credentials and recover the username and password. If an API key is embedded in the Basic Auth password (for example, using a static API token as the password), a network observer or a compromised proxy can expose that key directly. This pattern is common when teams repurpose HTTP Basic Auth to carry an API key instead of a traditional username/password pair, often to simplify client integration or avoid additional header logic.

In Rails, developers sometimes implement Basic Auth at the controller or web-server level and inadvertently log or expose headers. For instance, Rails logs the full HTTP request headers in development and, if not configured carefully, in production as well. If the Authorization header is included in logs, the base64-encoded credential string is persisted, creating a searchable artifact that can be leaked through log aggregation systems or access to log files. Additionally, if the application uses query parameters or URL fragments to pass the API key alongside Basic Auth, those values may be stored in server access logs, browser history, or referrer headers, further expanding the exposure surface.

The combination of Basic Auth and an API key also interacts poorly with intermediaries such as load balancers, reverse proxies, or CDNs. If these components terminate TLS but forward requests to the Rails app over plain HTTP internally, the Authorization header can be exposed within the internal network unless mTLS or other protections are enforced. Moreover, misconfigured CORS or permissive origin policies can allow client-side JavaScript to trigger cross-origin requests that include credentials, enabling browser-based leakage if the key is recoverable through a compromised frontend. Because the Basic Auth spec does not define additional protections like replay prevention or key rotation, a static API key encoded this way remains vulnerable until explicitly rotated after any suspected exposure.

middleBrick scans for these risks by inspecting the OpenAPI/Swagger specification, checking whether authentication schemes are declared as HTTP Basic and correlating runtime findings with header handling and logging behaviors. The scanner performs unauthenticated checks to identify endpoints that accept Basic Auth and flags scenarios where credentials or tokens appear in logs, error messages, or debug output. By cross-referencing spec definitions with observed responses, it highlights whether Authorization headers are transmitted in insecure contexts and provides prioritized findings with remediation guidance to reduce the likelihood of key disclosure.

To reduce exposure when using Basic Auth in Rails, avoid embedding API keys directly as passwords. Instead, use strong, rotated secrets for authentication and store credentials securely. When Basic Auth is required, enforce TLS end-to-end and ensure internal proxies also use encryption. Configure Rails and your web server to prevent Authorization header leakage in logs and error reports.

Example: Secure Basic Auth with a hashed secret

Store a hashed version of the secret in credentials and compare using ActiveSupport::SecurityUtils.secure_compare to avoid timing attacks.

Rails.application.credentials.basic_auth_secret_digest # stored as a hex or base64 digest

class ApplicationController < ActionController::Base
  before_action :authenticate_with_basic_auth

  private

  def authenticate_with_basic_auth
    authenticate_or_request_with_http_basic do |username, password|
      # Avoid using password directly as an API key; treat it as a shared secret
      expected_digest = Rails.application.credentials.basic_auth_secret_digest
      provided_digest = Digest::SHA256.base64digest(password)
      username == 'api_user' && ActiveSupport::SecurityUtils.secure_compare(provided_digest, expected_digest)
    end
  end
end

Example: Disable Authorization header logging

Configure Rails to filter sensitive headers and ensure your web server (e.g., NGINX, Puma) does not log the Authorization line. In config/application.rb or an environment-specific config, add:

config.filter_parameters += [:authorization]

For Puma, adjust the config/puma.rb or the web server configuration to exclude headers from access logs. With NGINX, use:

location / {
  proxy_pass http://rails_app;
  proxy_set_header Authorization "";
}

This prevents the raw Authorization header from being forwarded to Rails and avoids persisting it in access logs.

Example: Enforce TLS and use environment-based secrets

In production, require SSL and set the shared secret via environment variables, avoiding hardcoded values. In credentials.yml.enc, keep only non-sensitive defaults and load the API key from ENV:

class ApiController < ApplicationController
  before_action :require_tls_and_auth

  private

  def require_tls_and_auth
    unless request.ssl?
      head :forbidden
    end
    authenticate_with_basic_auth
  end
end

Rotate the shared secret regularly and audit access to credentials. Consider moving away from Basic Auth for new integrations in favor of token-based schemes with scoped permissions and short lifetimes, which reduce the impact of any single exposure.