Api Key Exposure in Hanami with Session Cookies

When an API key is embedded in a Hanami application and that key is transmitted or stored alongside session cookies, the combination can inadvertently expose sensitive credentials. Hanami applications often manage state using session cookies, which are typically stored as HTTP-only cookies to mitigate theft via client-side scripts. However, if an API key is included in the cookie payload, logged server-side, or reflected in responses, it can be exposed through insecure practices or misconfigurations. For example, if a developer stores an API key in the session store and the session cookie is not properly protected with Secure and SameSite attributes, an attacker who can intercept or predict session identifiers may gain access to both the session and the embedded API key.

Another exposure path occurs during debugging or logging. Hanami applications that log incoming cookies or session data without sanitization might inadvertently record API keys present in those sessions. This is particularly risky when session cookies are used for authentication and also carry authorization tokens such as API keys. The risk is compounded if the application uses the same session for multiple services, effectively creating a cross-service credential exposure chain. For instance, an attacker exploiting an SSRF or log injection flaw could retrieve session data containing an API key, leading to unauthorized access to third-party systems.

Additionally, if a Hanami application exposes an endpoint that returns session contents for diagnostic purposes and that endpoint does not enforce strict access controls, an API key stored in the session cookie can be leaked to unauthenticated users. Even when using encrypted session stores, if the encryption key is hardcoded or improperly managed, the confidentiality of API keys within session cookies may be compromised. These patterns align with common weaknesses listed in the OWASP API Top 10, particularly concerning security misconfigures and sensitive data exposure, and can be identified during a black-box scan that evaluates how session handling intersects with credential storage.

To mitigate API key exposure when using session cookies in Hanami, apply strict cookie attributes and avoid storing sensitive data such as API keys directly in session cookies. Instead, store only a session identifier in the cookie and keep sensitive data like API keys server-side in a secure store, referenced by the session ID.

# config/initializers/session.rb
Hanami.configure do |config|
  config.session = {
    key: '_my_app_session',
    httponly: true,
    secure: Rails.env.production?,
    samesite: :strict,
    expire_after: 30.minutes,
    encrypt: true
  }
end

Ensure that API keys are never serialized into the session object. For example, instead of assigning an API key to the session hash, retrieve it from a secure environment variable or vault at runtime based on the authenticated user’s permissions.

# app/controllers/application_controller.rb
class ApplicationController < Hanami::Action
  before_action :set_api_key_from_secure_store

  private

  def set_api_key_from_secure_store
    # Retrieve API key securely without storing in session
    @api_key = SecureStore.find_by(user_id: current_user.id).api_key
  end
end

When configuring session storage, prefer server-side stores such as encrypted cookies with strict integrity checks or external stores like Redis with TLS. Validate that session cookies include the Secure attribute in production to prevent transmission over unencrypted channels, and use SameSite=Strict or Lax to limit cross-origin exposure. Regularly rotate encryption keys and audit session handling logic to ensure no accidental logging of cookie data occurs.