Cors Wildcard in Rails

CORS wildcard configurations in Rails applications create critical security vulnerabilities by allowing unrestricted cross-origin access to your API endpoints. In Rails, this typically appears when developers use overly permissive settings in the cors.rb initializer or middleware configuration.

The most common manifestation is the wildcard origin setting:

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*' # DANGEROUS: allows any domain
    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options]
  end
end

This configuration allows any website to make requests to your Rails API, potentially exposing sensitive data or enabling CSRF attacks against authenticated users. The vulnerability becomes particularly dangerous when combined with Rails's session management or when APIs return personally identifiable information (PII).

Another Rails-specific pattern involves conditional wildcard origins that appear safe but aren't:

if Rails.env.development?
  config.middleware.use Rack::Cors do
    allow do
      origins '*' # Safe in dev, but often forgotten in production
      resource '/*', headers: :any, methods: :any
    end
  end
end

Developers often forget to restrict this when deploying to production, leaving the wildcard configuration active. Rails's environment-specific configuration makes this a common oversight.

Third-party gems can also introduce wildcard CORS vulnerabilities. For example, some Rails authentication gems or API documentation tools might automatically add permissive CORS configurations without clear documentation, creating a false sense of security.

The Rails asset pipeline and webpacker configurations can compound these issues. When frontend applications are served from different domains than the Rails API, developers might add overly permissive CORS settings to 'fix' development issues, inadvertently creating production vulnerabilities.

Detecting CORS wildcard vulnerabilities in Rails requires examining both configuration files and runtime behavior. Start by checking your config/initializers/cors.rb file for wildcard origins:

grep -r "origins ['\"]*['\"]" config/initializers/

Look for patterns like origins '*', origins :any, or conditional logic that might evaluate to a wildcard in production.

Examine your config/application.rb and environment-specific files (production.rb, staging.rb) for Rack::Cors middleware configuration. Rails applications often configure CORS in multiple locations, making comprehensive scanning essential.

Runtime detection with middleBrick provides automated verification of CORS configurations. The scanner tests your Rails API endpoints for permissive CORS headers by attempting cross-origin requests from different domains and analyzing the Access-Control-Allow-Origin responses.

middleBrick's Rails-specific detection includes:

• Configuration file analysis for wildcard origins and overly permissive settings
• Active testing of CORS preflight requests to verify actual behavior
• Detection of Rails-specific patterns like conditional wildcard origins based on environment
• Analysis of third-party gem configurations that might introduce CORS vulnerabilities
• Verification that CORS settings don't expose sensitive Rails endpoints (like /rails/info/properties)

The scanner also checks for Rails-specific endpoints that should never be accessible cross-origin, such as development server status pages or debug information that might be accidentally exposed in production.

For comprehensive coverage, middleBrick tests both authenticated and unauthenticated endpoints, as CORS vulnerabilities can expose different attack surfaces depending on the authentication state of the Rails application.

Remediating CORS wildcard vulnerabilities in Rails requires a security-first approach using Rails's native capabilities. The most secure configuration explicitly lists allowed origins:

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins ['https://your-frontend.com', 'https://app.yourcompany.com']
    resource '/*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options],
      credentials: true # Only if you need to send cookies
  end
end

For Rails applications with multiple frontend domains, consider using environment variables or a configuration file:

ALLOWED_ORIGINS = ENV.fetch('CORS_ALLOWED_ORIGINS', '').split(',').map(&:strip)

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins ALLOWED_ORIGINS
    resource '/*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options]
  end
end

This approach allows different origins per environment without code changes. For development, you might use a wildcard, but ensure it's restricted in production:

if Rails.env.production?
  origins = ['https://production-frontend.com']
else
  origins = ['http://localhost:3000', 'http://localhost:3001']
end

Consider using Rails's built-in before_action callbacks for fine-grained CORS control on specific controllers:

class Api::V1::UsersController < ApplicationController
  before_action :set_cors_headers, only: [:show, :update]

  private

  def set_cors_headers
    response.headers['Access-Control-Allow-Origin'] = 'https://frontend.com'
    response.headers['Vary'] = 'Origin'
  end
end

For Rails applications using JWT or token-based authentication, ensure CORS settings don't conflict with your auth strategy. The credentials: true option should only be used when necessary, as it allows sending cookies and HTTP authentication information.

middleBrick's remediation guidance includes specific Rails code examples and environment-specific configurations to ensure your CORS settings are secure across all deployment stages.