Api Key Exposure in Rails with Jwt Tokens

In Rails applications that use JWT tokens for authentication, developers sometimes store or transmit long-lived API keys or secrets alongside JWT handling logic, inadvertently creating exposure paths. A common pattern is embedding an API key inside a JWT payload or using the API key to sign or encrypt tokens in a way that makes the key accessible to unintended parties.

One specific risk arises when the Rails secret key base or a custom signing key is accidentally exposed in error messages, logs, or client-side code. If a JWT is constructed with secret_key_base or a related credential and that value is logged (for example, via Rails.logger.info "Token signed with: #{Rails.application.secrets.secret_key_base}"), an attacker who can read logs or error output may recover the key used to forge valid tokens.

Another exposure scenario occurs when a JWT is generated with embedded metadata that references an API key, such as including a database credential or an external service token inside the payload. Even if the JWT itself is cryptographically signed, the payload is typically base64-encoded (not encrypted by default), so anyone who intercepts the token can decode it and see the embedded API key. For example:

payload = { sub: user.id, api_key: ENV['EXTERNAL_SERVICE_KEY'], exp: 1.hour.from_now.to_i }
JWT.encode(payload, Rails.application.secrets.secret_key_base, 'HS256')

In this snippet, api_key is placed directly in the JWT payload. Because the payload is only base64-encoded, the API key is trivially recoverable. If the token is transmitted over an unencrypted channel or stored in an insecure client-side store, the API key can be leaked.

Additionally, misconfigured CORS or overly permissive route constraints in Rails can cause JWTs (and any API keys they contain) to be exposed to origins that should not have access. If the token is cached by a browser or an intermediary and later replayed, the embedded API key may be reused beyond its intended scope.

These combinations—JWT tokens carrying or being derived from sensitive API keys, plus weak logging, encoding-only protections, or relaxed transport and storage policies—create a scenario where an API key can be extracted, reused, or forged. The impact often maps to broken authentication and sensitive data exposure, which are highlighted in findings from security scans that evaluate authentication mechanisms and data exposure controls across the API surface.

To reduce risk, avoid placing API keys inside JWT payloads. If metadata about external services is required, store only a reference (such as an ID) in the token and map it to sensitive values server-side in a protected store.

When signing tokens, keep secrets out of logs and avoid printing secret material. Use environment variables managed by your deployment platform and ensure logs are sanitized. Instead of logging the secret key, log only non-sensitive identifiers:

# Avoid logging secrets; log only identifiers
Rails.logger.info "Issuing token for user_id=#{user.id}"

Generate tokens with a payload that excludes sensitive keys and set a reasonable expiration:

payload = { sub: user.id, exp: 1.hour.from_now.to_i }
encoded = JWT.encode(payload, Rails.application.secrets.secret_key_base, 'HS256')

For enhanced security, prefer asymmetric algorithms such as RS256, using a private key to sign and a public key to verify. Store the private key securely (for example, via Rails credentials or an environment variable) and keep the public key in a location accessible to verification logic:

# config/initializers/jwt.rb
PRIVATE_KEY = OpenSSL::PKey::RSA.generate(2048)
PUBLIC_KEY = PRIVATE_KEY.public_key

# Generating with RS256
payload = { sub: user.id, exp: 1.hour.from_now.to_i }
encoded = JWT.encode(payload, PRIVATE_KEY, 'RS256')

# Verifying with RS256
decoded = JWT.decode(token, PUBLIC_KEY, true, { algorithm: 'RS256' })

Ensure tokens are always transmitted over HTTPS and avoid storing them in local storage where they may be accessible to cross-site scripting. In Rails, set the secure and httponly flags on cookies if you use cookie-based storage, and configure CORS to allow only necessary origins:

# config/initializers/cors.rb
Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'https://trusted.example.com'
    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :delete, :options],
      expose: ['Authorization'],
      max_age: 86_400
  end
end

Rotate signing keys periodically and monitor for unexpected decoding errors that might indicate tampered tokens. By keeping API keys out of JWT payloads, avoiding secret leakage in logs, and using strong signing algorithms, you reduce the likelihood of token forgery and unauthorized access tied to exposed credentials.