Cors Wildcard in Sinatra

Cors Wildcard vulnerabilities in Sinatra applications typically emerge when developers use overly permissive CORS configurations to quickly solve cross-origin request issues during development. The most common manifestation appears when Sinatra applications use wildcard origins (*) without proper restrictions, allowing any website to make requests to your API and potentially access sensitive data.

In Sinatra, this often occurs when developers add a simple before filter like:

before do
  response.headers['Access-Control-Allow-Origin'] = '*'
end

This single line of code creates a significant security vulnerability. When combined with credentials (cookies, authorization headers), the wildcard origin becomes even more dangerous because browsers will block credentialed requests to wildcard origins, but some implementations incorrectly bypass this restriction.

Another Sinatra-specific manifestation involves improper handling of preflight requests. Developers might implement:

options "/api/*" do
  response.headers['Access-Control-Allow-Origin'] = '*'
  response.headers['Access-Control-Allow-Methods'] = 'GET, POST, PUT, DELETE, OPTIONS'
  response.headers['Access-Control-Allow-Headers'] = '*'
end

This pattern allows any origin to discover your API's capabilities and potentially exploit them. The wildcard headers enable attackers to probe your API structure without restrictions.

Credential leakage becomes possible when Sinatra applications use wildcard CORS alongside authentication middleware. Consider this problematic pattern:

before "/protected/*" do
  if authenticated?
    response.headers['Access-Control-Allow-Origin'] = '*'
    response.headers['Access-Control-Allow-Credentials'] = 'true'
  end
end

This configuration violates the CORS specification, which forbids credentialed requests to wildcard origins. Some browsers may reject these requests, but inconsistent implementations can lead to credential exposure across origins.

API enumeration attacks become trivial with wildcard CORS in Sinatra. Attackers can use tools like curl or browser-based scripts to systematically discover endpoints:

for path in ['/users', '/admin', '/config']
  curl -H "Origin: https://evil.com" -H "Access-Control-Request-Method: GET" -X OPTIONS https://your-api.com#{path}
  # Check response headers for Access-Control-Allow-Origin
end

The wildcard configuration provides immediate feedback about which endpoints are accessible, enabling attackers to map your API surface area without authentication.

Detecting CORS wildcard vulnerabilities in Sinatra applications requires examining both the application code and runtime behavior. Start by reviewing your Sinatra application files for wildcard patterns in CORS headers.

Code analysis should focus on these Sinatra-specific patterns:

grep -r "Access-Control-Allow-Origin.*\*" app/ lib/
grep -r "Access-Control-Allow-Headers.*\*" app/ lib/
grep -r "Access-Control-Allow-Methods.*\*" app/ lib/

Look for before filters and route handlers that set CORS headers without proper origin validation. Sinatra's flexible routing can make these vulnerabilities harder to spot, especially when using dynamic route patterns.

Runtime detection with middleBrick provides comprehensive coverage for Sinatra applications. The scanner tests CORS configurations by making cross-origin requests from multiple domains and analyzing the responses:

middlebrick scan https://your-sinatra-api.com
# The scanner will test:
# - Wildcard origin responses
# - Credential handling with wildcard origins
# - Preflight request handling
# - Header exposure through Access-Control-Expose-Headers

middleBrick's black-box scanning approach is particularly effective for Sinatra applications because it doesn't require access to source code. The scanner sends controlled cross-origin requests and analyzes the CORS headers in responses, detecting wildcard configurations that might be hidden in complex middleware chains.

Manual testing can complement automated scanning. Use curl to test CORS behavior:

curl -v -H "Origin: https://test.com" -X OPTIONS https://your-api.com/api/resource
# Look for Access-Control-Allow-Origin: *

Test with credentialed requests to verify if your Sinatra application improperly combines wildcards with Access-Control-Allow-Credentials.

Network analysis tools like Wireshark or browser developer tools can help identify CORS preflight requests and responses. Monitor for responses that include wildcard origins when making requests from different origins.

middleBrick provides Sinatra-specific detection capabilities by testing the actual runtime behavior of your API endpoints. The scanner's parallel testing approach can quickly identify CORS misconfigurations across your entire API surface, including endpoints that might only be accessible through specific Sinatra route patterns or middleware combinations.

Remediating CORS wildcard vulnerabilities in Sinatra requires implementing proper origin validation and restricting exposed resources. The most secure approach involves maintaining a whitelist of allowed origins and validating requests against this list.

Implement origin validation using Sinatra's before filter:

ALLOWED_ORIGINS = ['https://yourdomain.com', 'https://yourapp.com']

before do
  request_origin = request.env['HTTP_ORIGIN']
  if ALLOWED_ORIGINS.include?(request_origin)
    response.headers['Access-Control-Allow-Origin'] = request_origin
    response.headers['Vary'] = 'Origin'
  end
end

This pattern ensures only trusted origins receive CORS headers. The Vary header is crucial for caching behavior and prevents intermediate proxies from serving responses to unauthorized origins.

For applications requiring credentials, implement strict origin validation:

before "/api/*" do
  request_origin = request.env['HTTP_ORIGIN']
  if ALLOWED_ORIGINS.include?(request_origin)
    response.headers['Access-Control-Allow-Origin'] = request_origin
    response.headers['Access-Control-Allow-Credentials'] = 'true'
    response.headers['Access-Control-Allow-Methods'] = 'GET, POST, PUT, DELETE, OPTIONS'
    response.headers['Access-Control-Allow-Headers'] = 'Authorization, Content-Type'
    response.headers['Access-Control-Max-Age'] = '86400'
  end
end

Handle preflight requests properly by defining an options route:

options "/api/*" do
  request_origin = request.env['HTTP_ORIGIN']
  if ALLOWED_ORIGINS.include?(request_origin)
    halt 200, {
      'Access-Control-Allow-Origin' => request_origin,
      'Access-Control-Allow-Methods' => 'GET, POST, PUT, DELETE, OPTIONS',
      'Access-Control-Allow-Headers' => 'Authorization, Content-Type',
      'Access-Control-Max-Age' => '86400'
    }
  else
    halt 403, 'Forbidden Origin'
  end
end

Restrict exposed headers to only what's necessary:

response.headers['Access-Control-Expose-Headers'] = 'Content-Type, X-Custom-Header'

Configure middleware for production deployments. If using Rack middleware for CORS, ensure proper configuration:

use Rack::Cors do
  allow do
    origins ALLOWED_ORIGINS
    resource "/api/*",
      headers: :any,
      methods: [:get, :post, :put, :delete, :options],
      credentials: true
  end
end

Test your remediation using middleBrick to verify the CORS configuration is now secure:

middlebrick scan https://your-sinatra-api.com
# Verify no wildcard CORS findings and proper origin validation

Implement logging for CORS requests to monitor for suspicious cross-origin activity:

before do
  if request.env['HTTP_ORIGIN'] && !ALLOWED_ORIGINS.include?(request.env['HTTP_ORIGIN'])
    logger.warn "CORS request from unauthorized origin: #{request.env['HTTP_ORIGIN']}"
  end
end

Consider environment-specific CORS policies, allowing broader origins in development while maintaining strict controls in production. Use environment variables to configure allowed origins dynamically.