Api Key Exposure in Rails with Api Keys

In Ruby on Rails applications, storing and transmitting API keys as if they were regular configuration values is a common pattern that can lead to inadvertent exposure. Rails convention encourages placing keys in environment files, credentials, or encrypted secrets, but developers sometimes embed keys directly in initializers, environment variables that are logged, or in JavaScript sent to the browser. When API keys are handled this way, the attack surface expands because keys can leak through logs, error pages, source control, or client-side code.

For example, placing a raw key in config/initializers/api_keys.rb as a plain Ruby constant can expose the key in memory and in version control if the file is accidentally committed. Consider this non-secure pattern:

API_KEYS = {
  stripe: ENV['STRIPE_KEY'],
  sendgrid: 'SG.xxxxxx.yyyyyy' # hardcoded
}

Here, ENV['STRIPE_KEY'] may be safe if the environment is properly managed, but hardcoding any portion of the key in the repository is hazardous. If an attacker gains read access to the repository or the runtime environment (for example via a path traversal or log exposure), the key is immediately usable.

Another common vector is logging. Rails logs environment variables and parameters at various levels. If an API key is passed as a query parameter or in request headers and the application logs the full request, the key can end up in log aggregation systems. A typical vulnerable controller might look like:

class PaymentsController < ApplicationController
  def create
    logger.info "Processing with key: #{params[:api_key]}"
    # payment logic
  end
end

Such logging can inadvertently expose keys in structured logs or error traces. Environment-specific behavior also matters: in development mode, Rails often prints more context, increasing the chance of key exposure in developer consoles or terminal history.

Keys exposed in JavaScript are particularly dangerous because they are delivered to every browser that visits the site. If a Rails view embeds an API key in JavaScript, any user can inspect the page source and extract it:

<script>
  const apiKey = "<%= ENV['PUBLIC_MAP_KEY'] %>";
  initializeMap(apiKey);
</script>

Even though the key is read from an environment variable, rendering it into client-side code turns it into a publicly retrievable credential. Attackers can harvest these keys and abuse associated quotas or access controls.

Finally, misconfigured deployment pipelines can amplify exposure. If CI/CD injects secrets into build-time environment variables and the build artifacts or Docker images are improperly stored, keys can persist in images or configuration snapshots. Rails applications that rely on unchecked .env files or shared configuration across environments without encryption further increase the risk.

To reduce the risk of API key exposure in Rails, treat keys as sensitive credentials that must never appear in logs, source control, or client-side code. Use Rails encrypted credentials or environment-specific secrets management, and ensure runtime handling minimizes exposure.

Store keys securely using Rails credentials or encrypted secrets. For example, edit the encrypted credentials with bin/rails credentials:edit and add:

stripe_key: sk_live_xxx
sendgrid_api_key: SG.xxxxxx.yyyyyy

Then reference them safely in initializers:

API_KEYS = {
  stripe: Rails.application.credentials.dig(:stripe_key),
  sendgrid: Rails.application.credentials.dig(:sendgrid_api_key)
}

This keeps keys out of version control and allows per-environment values via the encrypted file or environment variable providers.

Avoid logging sensitive parameters. In controllers, filter keys and do not log raw values:

class PaymentsController < ApplicationController
  def create
    # Process payment without logging the key
    key_present = params[:api_key].present?
    # payment logic
  end
end

If you must record activity, log only metadata such as request IDs and ensure logs are protected with access controls.

Never embed API keys in JavaScript sent to the browser. Instead, proxy requests through a Rails controller or endpoint that injects the key server-side:

class MapsController < ApplicationController
  def map_key
    render json: { key: Rails.application.credentials.dig(:map_key) }
  end
end

In the frontend, fetch the key from this endpoint rather than embedding it directly. This keeps the credential on the server and limits exposure to authenticated or authorized clients.

During deployment, ensure secrets are injected at runtime rather than baked into images. Use environment variables provided by your hosting platform, and validate that no secrets are present in Dockerfiles or build scripts. Regularly rotate keys and monitor for unauthorized usage to further reduce impact.