Api Key Exposure in Grape with Openid Connect

Grape is a REST-like API micro-framework for Ruby, often used to build JSON APIs. When OpenID Connect (OIDC) is integrated—typically via gems such as doorkeeper or omniauth-openid-connect—developers may inadvertently expose API keys through improper handling of tokens, secrets, or introspection endpoints.

One common pattern is storing an API key as a bearer token or client secret in the OIDC configuration. If the Grape endpoint returns this key in logs, error messages, or HTTP responses (for example, via a misconfigured Authorization header reflection or a verbose env dump), an authenticated or unauthenticated attacker can harvest the key. This exposure is especially risky when token introspection or userinfo endpoints reveal internal identifiers that can be chained to other vulnerabilities such as IDOR or BFLA.

Consider an endpoint that accepts an Authorization: Bearer <key> header and passes it to an OIDC provider for validation. If Grape logs the incoming header verbatim, the API key can appear in plaintext in application or web server logs. Additionally, if the OIDC integration uses dynamic client registration and the client secret is stored in a database or configuration without encryption, a path traversal or deserialization bug could read that secret. Even when using standard OIDC flows (authorization code or client credentials), failing to restrict the scope and aud claims can cause the API key (or token) to be accepted from unintended issuers, effectively leaking it to unauthorized parties.

Because Grape often serves as a lightweight backend for mobile or single-page applications, developers may mistakenly treat OIDC as both authentication and authorization without a complementary scope or claim check. This can lead to an over-privileged API key being accepted across multiple routes. When combined with missing rate limiting or weak input validation on the token parameter, an attacker can automate leakage through error handling or timing differences.

In practice, the risk is not theoretical: public bug reports and CVE entries have shown API keys leaked through verbose error messages and misconfigured introspection URLs. The combination of Grape’s flexibility and OIDC’s complexity increases the attack surface if secrets are handled as request parameters or logged diagnostic data. Detection involves scanning for endpoints that echo the Authorization header, expose configuration via debug routes, or return detailed errors containing tokens.

middleBrick scans such endpoints in black-box mode, identifying whether API keys appear in responses, logs, or metadata. By correlating OIDC configuration findings with input validation and data exposure checks, it surfaces specific paths where keys could be exfiltrated, providing prioritized remediation guidance aligned with OWASP API Top 10 and relevant compliance mappings.

Remediation focuses on ensuring secrets are never reflected in responses or logs and that tokens are validated against strict OIDC configuration.

Example: Secure OIDC setup with Doorkeeper and Grape

Use environment variables for secrets, avoid logging headers, and enforce token audience and issuer validation.

# config/initializers/doorkeeper.rb
Doorkeeper.configure do
  orm :active_record

  # Store secrets in environment variables; never in code or logs
  secret_file_path = File.join(Rails.root, 'config', 'oauth_secret.key')
  secret = File.read(secret_file_path).strip

  access_token_expires_in 2.hours

  # Enforce HTTPS in production
  force_ssl_in_redirect_url!

  # Validate issuer and audience to prevent acceptance from malicious providers
  grant_flows %w[authorization_code client_credentials]

  # Explicitly disable introspection if not needed, or lock it to a trusted endpoint
  # Avoid exposing client secrets via introspection responses
end

Grape endpoint with strict scope and audience checks:

# app/api/v1/base.rb
class API::V1::Base < Grape::API
  format :json

  helpers do
    def current_user
      # Validate token against OIDC provider’s JWKS, not just presence
      token = request.env['HTTP_AUTHORIZATION']&.split(' ')&.last
      return nil unless token

      # Use a vetted OIDC gem to verify issuer, audience, and signature
      # Example with ruby-jwt and a cached JWKS:
      # payload = OIDC::Validator.new(token, ENV['OIDC_ISSUER']).verify!
      # { sub: payload['sub'], scope: payload['scope'] }
      # For illustration, we show a minimal placeholder:
      { sub: 'verified_user', scope: 'api_read api_write' }
    rescue JWT::DecodeError, OIDC::ValidationError
      error!('Unauthorized', 401)
    end

    def require_scope!(expected)
      scopes = current_user&.dig(:scope)&.split || []
      missing = expected.reject { |s| scopes.include?(s) }
      error!("Insufficient scope: #{missing.join(', ')}", 403) unless missing.empty?
    end
  end

  # Protect routes with scope requirements
  before { require_scope!(['api_read']) }

  get :profile do
    { user_id: current_user[:sub], scopes: current_user[:scope] }
  end

  # Admin route with restricted scope
  at_exit { require_scope!(['api_read', 'api_write', 'admin']) }  # dummy for example
  get :admin do
    { status: 'admin' }
  end
end

Key practices:

• Never log the full Authorization header or token values.
• Store OIDC client secrets and API keys in environment variables or a secrets manager; avoid configuration files in version control.
• Validate iss (issuer), aud (audience), and token signatures on every request; do not rely on opaque bearer tokens alone.
• Define and enforce granular scopes per route; avoid accepting tokens with broad or missing scopes.
• Disable verbose error reporting in production; ensure error messages do not echo back tokens or internal identifiers.

middleBrick can validate these controls by checking whether endpoints inadvertently reflect tokens, whether OIDC metadata is overly permissive, and whether sensitive data appears in responses. Its findings map to OWASP API Top 10 categories and can be integrated into CI/CD via the GitHub Action or MCP Server to fail builds when risky configurations are detected.