Cors Wildcard in Sinatra with Api Keys

A CORS wildcard (Access-Control-Allow-Origin: *) combined with API key authentication in a Sinatra service can unintentionally expose protected endpoints to any origin. When the server responds with a wildcard, browsers allow any website to read the response, even when an API key is required for access. Because the API key is typically sent in a header (e.g., X-API-Key), a page hosted on an attacker-controlled site can make a cross-origin request that includes the key, effectively bypassing the same-origin policy intended to isolate resources.

In Sinatra, this often occurs when middleware or route logic sets Access-Control-Allow-Origin: * indiscriminately, even when credentials or keys are used. The CORS protocol treats wildcard origins as incompatible with credentials, but many clients and servers still process them, leading to confusion. An attacker can craft a simple script that calls the Sinatra endpoint from the browser, leveraging the wildcard to read data that should be restricted. This becomes a data exposure vector when the API key is static, leaked in client-side code, or reused across environments.

For example, a Sinatra route that sets both the wildcard and exposes an API key header might look like this in a vulnerable configuration:

require 'sinatra'
require 'json'

before do
  headers 'Access-Control-Allow-Origin' => '*',
          'Access-Control-Allow-Headers' => 'X-API-Key, Content-Type'
end

get '/internal/data' do
  if env['HTTP_X_API_KEY'] == 'fixed-secret-key'
    { status: 'ok', data: 'confidential' }.to_json
  else
    status 401
    { error: 'unauthorized' }.to_json
  end
end

In this setup, the browser enforces CORS, but because the origin is a wildcard, a malicious site can load the endpoint in an XMLHttpRequest or fetch call. If the attacker’s page includes the correct API key (e.g., obtained through source code exposure or social engineering), the request succeeds and the response is readable. This violates the principle that authentication mechanisms should not be undermined by relaxed CORS policies.

The risk is especially acute for unauthenticated attack surface scans, where endpoints that require API keys are still exposed to origins they should not be. MiddleBrick’s checks for Data Exposure and Unsafe Consumption can detect such misconfigurations by analyzing the OpenAPI spec and runtime behavior, highlighting where a wildcard origin coexists with key-based controls. Without additional constraints, the combination of CORS wildcard and API keys creates a scenario where protection mechanisms are effectively neutralized.

To secure a Sinatra API that uses API keys, avoid broad CORS policies and instead adopt an origin-allowlist approach. Define specific origins that are permitted, and ensure that wildcard origins are never used when authentication headers or keys are involved. You should also scope CORS headers to only the routes that require them and avoid leaking API keys in logs or error messages.

Below is a hardened example that replaces the wildcard with a controlled list of origins and conditionally sets CORS headers only for authenticated or preflight requests:

require 'sinatra'
require 'json'

ALLOWED_ORIGINS = ['https://trusted.example.com', 'https://app.example.com'].freeze

before do
  origin = request.env['HTTP_ORIGIN']
  if ALLOWED_ORIGINS.include?(origin)
    headers 'Access-Control-Allow-Origin' => origin,
            'Access-Control-Allow-Headers' => 'X-API-Key, Content-Type',
            'Access-Control-Allow-Methods' => 'GET, OPTIONS'
  end
end

options '*'

get '/internal/data' do
  halt 401, { error: 'unauthorized' }.to_json unless env['HTTP_X_API_KEY'] == 'fixed-secret-key'
  { status: 'ok', data: 'confidential' }.to_json
end

This approach ensures that only known origins can access the endpoint, reducing the attack surface. For APIs consumed by web applications, you can also use environment variables to manage allowed origins so that configuration changes do not require code modifications:

ALLOWED_ORIGINS = (ENV['CORS_ORIGINS'] || 'https://trusted.example.com').split(',').map(&:strip).freeze

Additionally, avoid echoing the API key in responses or error bodies. Ensure that logs do not capture keys in plaintext, and consider rotating keys regularly. MiddleBrick’s scans, whether run via the CLI or integrated into CI/CD with the GitHub Action, can verify that your Sinatra routes do not expose wildcard origins alongside key-based authentication. The dashboard can help you track changes over time, and the MCP Server allows you to validate configurations directly from your development environment.

When continuous monitoring is enabled under the Pro plan, Sinatra services are rescanned on a configurable schedule, so any regression that reintroduces a wildcard is flagged promptly. This helps maintain a secure posture as the application evolves.