Api Key Exposure in Grape with Bearer Tokens

Grape is a REST-like API micro-framework for Ruby that allows developers to define endpoints and authentication schemes with minimal ceremony. When Bearer Tokens are used for authentication, an API key is typically passed in the Authorization header as Authorization: Bearer <token>. This pattern is common because it is simple and works well with HTTP proxies and API gateways. However, this simplicity creates risk when tokens are inadvertently exposed.

Exposure can occur through server-side logging, error messages, or misconfigured middleware that echoes headers. For example, if a Grape API logs incoming requests including headers and the token appears in logs, it becomes a data exposure finding. In a black-box scan, middleBrick tests whether the API reflects the Authorization header in responses or error payloads, which can lead to unauthorized access if tokens are leaked.

Another exposure vector is improper handling of CORS and preflight requests. Grape APIs that do not restrict origins or headers may allow browser-based JavaScript to read responses that include authenticated data, effectively exposing the token to a malicious page. The scan checks for missing Access-Control-Allow-Origin restrictions and overly permissive headers that facilitate token leakage via cross-origin requests.

Additionally, if the API serves documentation or debug endpoints that echo the Authorization header, an attacker can harvest tokens by probing these routes. middleBrick’s endpoints inventory and unauthenticated scanning detect such debug routes and flag them as part of the Inventory Management and Unsafe Consumption checks. Because Bearer Tokens are static secrets, any exposure in these contexts effectively compromises the entire authentication boundary, making this a high-severity concern in the Data Exposure category.

From an authentication perspective, relying solely on Bearer Tokens without additional protections such as short lifetimes or scope restrictions increases the impact of exposure. middleBrick’s Authentication check verifies whether the API consistently requires Authorization for protected routes and whether tokens are transmitted only over encrypted channels. Without transport encryption, tokens can be intercepted, which is why the Encryption check is critical when Bearer Tokens are in use.

Remediation focuses on minimizing the token’s exposure surface and ensuring secure handling within the Grape API. The following examples show secure patterns for using Bearer Tokens in Grape.

1. Require Authorization for all relevant endpoints

Use a before block to enforce token validation and avoid accidental public exposure.

require 'grape'

class MyAPI < Grape::API
  format :json

  before do
    # Ensure Authorization header is present and valid
    header_params = env['HTTP_AUTHORIZATION']
    unless header_params&.start_with?('Bearer ')
      error!('Unauthorized', 401)
    end
    token = header_params.split(' ').last
    # Validate token against a secure store or JWT verification
    # For example, using JWT:
    # begin
    #   JWT.decode(token, Rails.application.secrets.secret_key_base, true, { algorithm: 'HS256' })
    # rescue JWT::DecodeError
    #   error!('Invalid token', 401)
    # end
  end

  resource :public do
    get do
      { message: 'Public endpoint, no auth required' }
    end
  end

  resource :secure do
    get do
      { message: 'Authenticated access granted' }
    end
  end
end

2. Avoid logging sensitive headers

Configure your logger to exclude Authorization headers to prevent token leakage in logs.

# config/initializers/filter_parameter_logging.rb
Rails.application.config.filter_parameters += [:authorization, :HTTP_AUTHORIZATION]

# In your Grape middleware or logger wrapper, skip logging headers containing 'authorization'
class SafeLogger
  def initialize(app)
    @app = app
  end

  def call(env)
    request = Rack::Request.new(env)
    env['HTTP_AUTHORIZATION'] = '[FILTERED]' if env['HTTP_AUTHORIZATION']
    @app.call(env)
  end
end

3. Restrict CORS origins and headers

Ensure the API does not inadvertently allow any origin to read authenticated responses.

require 'grape'

class MyAPI < Grape::API
  include Grape::Kraken::Helpers

  before { headers['Access-Control-Allow-Origin'] = 'https://trusted.example.com' }
  before { headers['Access-Control-Allow-Methods'] = 'GET, POST, OPTIONS' }
  before { headers['Access-Control-Allow-Headers'] = 'Authorization, Content-Type' }

  options '*' do
    headers['Access-Control-Allow-Origin'] = 'https://trusted.example.com'
    headers['Access-Control-Allow-Methods'] = 'GET, POST, OPTIONS'
    headers['Access-Control-Allow-Headers'] = 'Authorization, Content-Type'
    200
  end
end

4. Serve documentation without echoing tokens

If using a doc endpoint, ensure it does not reflect the Authorization header directly.

resource :docs do
  before { # Do not forward or log Authorization header }
  get do
    { endpoints: [
        { path: '/secure', method: 'GET', description: 'Requires Bearer Token' }
      ]
    }
  end
end

These fixes reduce the likelihood of token exposure through logging, cross-origin leakage, and improper validation. middleBrick’s scans can verify that these protections are in place by checking endpoint behavior and headers, helping teams align with OWASP API Top 10 and related compliance guidance.