Api Key Exposure in Rails with Saml

When a Ruby on Rails application uses SAML for authentication, developers sometimes conflate session-based web security with the protection of service credentials such as API keys. This can lead to scenarios where an API key is inadvertently exposed through the SAML flow or through related integration points. Common causes include storing API keys in Rails session data that may be serialized into SAML responses or assertions, embedding keys in controller actions that are invoked after a SAML login, or logging sensitive parameters that include key material when SAML events are traced.

Rails’ default behavior for parameter parsing and session storage can inadvertently mirror sensitive information if developers do not explicitly filter key-like parameters from logs and from attributes that are marshalled into SAML metadata or name identifier mappings. For example, a controller that calls an external service using a read API key stored in ENV is generally safe, but if that key is also placed into the Rails session or passed as a query parameter during SAML attribute mapping, it may be exposed to logs, browser history, or misconfigured identity providers that include user data in SAML responses.

Additionally, misconfigured SAML endpoints can expose integration details. If a Rails app exposes a metadata endpoint at a predictable route and does not restrict access, an unauthenticated attacker can retrieve the SAML configuration, including certificate fingerprints and endpoints, which can aid in crafting token‑based attacks that pivot to API key–protected services. Insecure transmission or weak certificate validation in the SAML consumer can also expose assertions containing user identifiers that, when correlated with logs containing API key usage, increases the risk of cross‑context leakage.

Another vector involves the use of SAML name identifiers and session cookies together. If a Rails session is tied to a SAML name identifier without additional protections, and that session is used to authorize calls to an API that requires a key, an attacker who hijacks the session could leverage the existing key if it is stored insecurely or reused across contexts. The combination of a permissive SameSite or missing Secure flag on the session cookie and a SAML flow that does not enforce strict recipient and destination validation can amplify exposure risks.

To assess the risk, middleBrick runs checks such as Data Exposure and Authentication in parallel, correlating findings with the presence of SAML integrations. The tool does not assume intent but highlights configurations where API keys appear in query strings, logs, or session attributes alongside SAML endpoints, providing prioritized findings with severity levels and remediation guidance mapped to frameworks like OWASP API Top 10 and PCI-DSS.

Remediation focuses on preventing API key leakage through session data, logs, and SAML metadata while maintaining a secure SAML integration. Follow these concrete steps and code examples in your Rails application.

• Filter sensitive parameters globally to prevent keys from appearing in logs or being captured in SAML-related attributes. Add this to config/initializers/filter_parameter_logging.rb:

Rails.application.config.filter_parameters += [:api_key, :secret_key, :access_token]

• Ensure your SAML configuration does not embed API keys in name identifiers or attributes. In config/initializers/saml.rb, keep assertions focused on identity and avoid passing raw keys:

SAML.configure do |config|
  config.issuer = 'https://app.example.com'
  config.assertion_consumer_service_url = '/saml/consume'
  config.name_identifier_format = 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'
  # Do not include API keys in attributes or name identifiers
  config.attributes = {
    email: 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress',
    name_id: 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name'
  }
end

• Store API keys in environment variables and reference them securely in initializers or service objects without persisting them to the session. Example service object:

class ExternalApiClient
  def initialize
    @api_key = ENV.fetch('EXTERNAL_API_KEY')
  end

  def call
    response = Faraday.get('https://api.example.com/v1/resource', nil, { 'Authorization' => "Bearer #{@api_key}" })
    raise 'Unauthorized' unless response.success?
    response.body
  end
end

• Apply secure session cookie settings in config/initializers/session_store.rb to reduce the risk of session hijack that could lead to API key misuse:

Rails.application.config.session_store :cookie_store,
  key: '_app_session',
  same_site: :strict,
  secure: Rails.env.production?,
  httponly: true

• Restrict access to the SAML metadata endpoint in routes and firewall rules. In config/routes.rb, limit by IP or require an allowlist:

Rails.application.routes.draw do
  get '/saml/metadata', to: 'saml#metadata'
  # Consider adding IP restrictions in production via firewall or route constraint
end

• Audit logs to ensure SAML events do not include API key parameters. Use Rails tagged logging or custom filters to redact sensitive keys from the SAML request/response logs.

middleBrick’s GitHub Action can be added to CI/CD pipelines to fail builds if risk scores drop below your defined threshold, ensuring that new SAML or API key configurations are automatically validated before deployment. The Web Dashboard and CLI allow you to track changes over time and maintain continuous visibility without requiring manual review of every commit.