Cors Wildcard in Sinatra with Cockroachdb

A CORS wildcard in a Sinatra application that serves data from Cockroachdb can unintentionally expose cross-origin requests to sensitive database-backed resources. When Access-Control-Allow-Origin: * is set broadly and the backend integrates directly with Cockroachdb, any origin can trigger API endpoints that query or mutate database rows. This becomes a critical exposure when endpoints rely on unauthenticated or weakly authorized access, because the wildcard removes origin-based filtering that would otherwise limit which web applications can read or write data.

In a Sinatra app, developers sometimes apply a global CORS header such as allow 'Access-Control-Allow-Origin', '*' for convenience during development or to support simple public clients. When such endpoints call into Cockroachdb—whether through an ORM, direct SQL, or a connection pool—lack of per-request authorization or insufficient validation means any external site can drive queries through the browser’s same-origin policies being bypassed. For example, a public JavaScript frontend hosted on an attacker-controlled domain can issue authenticated-looking requests if cookies or tokens are inadvertently included, leveraging the wildcard to harvest data that should be restricted to specific origins.

The interaction with Cockroachdb amplifies the risk because database-backed APIs often expose more than intended when CORS is too permissive. Query parameters, filters, and endpoints reflecting database identifiers can be probed by an attacker to enumerate schemas, test for SQL injection, or trigger excessive reads/writes. Even if the Sinatra layer performs some validation, a missing or misconfigured CORS rule can allow browser-based scripts to make cross-origin calls that the server processes, effectively bypassing intended same-origin protections. This is especially risky when combined with other findings such as BOLA/IDOR or missing rate limiting, as the wildcard grants easy, repeated access from malicious origins.

Moreover, preflight requests handled by Sinatra may return the wildcard along with permissive methods and headers, signaling to browsers that any site can interact with the API. If Cockroachdb queries are executed in response to these requests without strict referer checks or CSRF mitigations, the application can be abused for unauthorized data access or to drive unwanted database load. The key issue is that CORS is a browser-enforced mechanism; once the wildcard is in place, the server must rely entirely on its own authorization logic, which may be incomplete when integrating with Cockroachdb.

To secure a Sinatra app integrating with Cockroachdb, replace broad CORS rules with origin allowlists and enforce strict authorization on every database interaction. Below are concrete, working examples in Ruby using common libraries, demonstrating how to configure CORS safely and query Cockroachdb with proper checks.

1. Configure a targeted CORS policy in Sinatra

Instead of a wildcard, explicitly allow known origins and propagate safe headers. This example uses the sinatra-cross_origin gem to control CORS at the route level:

# Gemfile: gem 'sinatra-cross_origin'
require 'sinatra'
require 'sinatra/cross_origin'

configure do
  enable :cross_origin
  set :allow_origins, ['https://trusted.example.com', 'https://app.middlebrick.example']
  set :allow_methods, %w[GET POST OPTIONS]
  set :allow_headers, %w[Content-Type Authorization]
  set :expose_headers, %w[X-Rate-Limit]
  set :max_age, 3600
end

before do
  cross_origin
end

get '/api/reports/:id' do
  # Authorization and ownership checks must happen here
  report = fetch_report(params[:id])
  report.to_json
end

options '*': do
  status 200
  body ''
end

2. Cockroachdb query with ownership and parameterized inputs

Use parameterized SQL to prevent injection and validate that the requesting user or token can access the specific row. This example uses the pg gem directly:

require 'pg'
require 'sinatra'

configure do
  @db = PG.connect(
    host: ENV['COCKROACH_HOST'],
    port: ENV['COCKROACH_PORT'],
    dbname: ENV['COCKROACH_DB'],
    user: ENV['COCKROACH_USER'],
    password: ENV['COCKROACH_PASSWORD']
  )
end

helpers do
  def fetch_report(report_id)
    user_id = current_user_id # derived from token/session
    sql = 'SELECT id, tenant_id, data FROM reports WHERE id = $1 AND tenant_id = $2'
    result = @db.exec_params(sql, [report_id, user_id])
    halt 404, { error: 'Not found' }.to_json if result.ntuples.zero?
    result.first
  end
end

get '/api/reports/:id' do
  halt 401, { error: 'Unauthorized' }.to_json unless authorized_own_report?(params[:id])
  report = fetch_report(params[:id])
  report.to_json
end

3. Enforce per-request authorization and avoid wildcard origins in production

Ensure the Sinatra app validates both CORS origin and database ownership for every request. Combine this with environment-specific configurations so that development can be more permissive while production uses strict allowlists:

configure :production do
  set :allow_origins, ENV.fetch('ALLOWED_ORIGINS', '').split(',').map(&:strip)
end

configure :development do
  set :allow_origins, ['http://localhost:3000', 'http://127.0.0.1:3000']
end

By narrowing CORS origins and validating each Cockroachdb query against the authenticated subject, you prevent wildcard-driven cross-origin abuse while preserving functionality for legitimate clients.