Cors Wildcard in Rails with Dynamodb

A CORS wildcard in a Rails API that uses DynamoDB as a backend data store can unintentionally expose sensitive data and increase the impact of misconfigured access controls. When config.action_dispatch.allowed_origins is set to * in environments such as development or, mistakenly, in production, the Rails application permits any origin to make authenticated requests via credentials or elevated headers. Because the Rails app queries DynamoDB on behalf of the client, either through server-side code or via pre-signed URLs, the wildcard allows an attacker-controlled site to make requests that include credentials, such as session cookies or OAuth tokens, leveraging the browser’s same-origin policies to perform authenticated actions.

The risk is compounded when DynamoDB permissions are broader than intended. For example, an IAM role attached to the Rails service may include dynamodb:GetItem and dynamodb:Query on tables that contain user data. If the Rails endpoint does not enforce strict ownership checks—such as validating that the requested item’s partition key matches the authenticated user’s ID—an attacker can iterate over identifiers by leveraging the wildcard CORS origin to make repeated calls. This can lead to Insecure Direct Object References (IDOR) or Broken Object Level Authorization (BOLA), where data belonging to other users is accessed through predictable keys.

In addition, wildcard CORS can interact poorly with preflight requests. Browsers send an OPTIONS request when custom headers or non-simple methods are used. If the Rails app responds with Access-Control-Allow-Origin: * and does not validate the Origin header against a strict allowlist, malicious JavaScript can repeatedly invoke endpoints that trigger DynamoDB scans or queries. Even if the DynamoDB table enforces fine-grained IAM policies at the backend, the Rails application’s permissive CORS setting can circumvent intended isolation, because the application layer is the one exposed to the browser’s cross-origin rules.

Real-world attack patterns mirror items found in the OWASP API Top 10, such as BOLA and IDOR, and can be discovered during a black-box scan that tests unauthenticated and authenticated scenarios. A scanner can detect a wildcard CORS header and flag it alongside missing origin validation, highlighting that the Rails app does not correlate the authenticated identity with the DynamoDB request. This combination means that an attacker can potentially retrieve or modify data belonging to other users by chaining CORS misconfiguration with insufficient data-level authorization in the application code.

Because DynamoDB is often used for scalable, structured storage, developers may assume that tight IAM policies alone are sufficient. However, if the Rails application does not enforce ownership checks at the model or service layer—such as ensuring that a userId attribute matches the authenticated user’s ID—wildcard CORS provides an easy path to abuse. Proper remediation requires both server-side origin validation and strict per-request authorization that ties DynamoDB keys to the authenticated subject, ensuring that even if CORS is broad, the data access layer remains constrained.

To secure a Rails API that uses DynamoDB, you must address CORS at the Rails level and enforce ownership checks at the DynamoDB access layer. Below are concrete code examples that demonstrate these fixes.

1. Restrict CORS origins in Rails

Instead of allowing all origins, specify an explicit allowlist. In config/application.rb or an environment-specific file, configure allowed origins based on your frontend domains.

# config/initializers/cors.rb
Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'https://app.example.com', 'https://admin.example.com'
    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options],
      expose: ['X-Request-ID'],
      credentials: true
  end
end

This ensures that only known origins can make cross-origin requests with credentials, reducing the risk of unauthorized cross-site interactions.

2. Validate ownership in Rails models and services

Before querying DynamoDB, ensure that the requested resource belongs to the authenticated user. Assuming you have a current_user method and a DynamoDB client configured, implement a service object that enforces ownership.

# app/services/dynamodb_item_service.rb
class DynamodbItemService
  def initialize(user_id, dynamodb_client = Aws::DynamoDB::Client.new)
    @user_id = user_id
    @dynamodb = dynamodb_client
  end

  def get_item(table_name, item_id)
    response = @dynamodb.get_item(
      table_name: table_name,
      key: {
        'id' => { s: item_id },
        'user_id' => { s: @user_id }
      }
    )
    response.item || raise(NotAuthorizedError, 'Item not found or access denied')
  end

  def list_items(table_name, filter = {})
    # Ensure partition key includes user_id to prevent scanning other users' data
    response = @dynamodb.query(
      table_name: table_name,
      key_condition_expression: 'user_id = :uid',
      expression_attribute_values: {
        ':uid' => { s: @user_id }
      },
      filter_expression: build_filter_expression(filter)
    )
    response.items
  end

  private

  def build_filter_expression(filter)
    # Implement safe filter building to avoid injection
    # Example filter: { status: 'active' }
    conditions = filter.map { |k, v| "#{k} = :#{k}" }
    { expression: conditions.join(' AND '), values: filter.transform_values { |v| { s: v } } }
  end
end

This pattern ensures that every DynamoDB request includes the authenticated user’s ID both as part of the key condition and as an ownership check, preventing horizontal privilege escalation even if CORS is permissively configured.

3. Use pre-signed URLs with scoped permissions

If serving files or allowing direct uploads to S3 via DynamoDB metadata, generate pre-signed URLs with limited scope and time-bound tokens instead of wide IAM permissions.

# app/controllers/files_controller.rb
def presigned_url
  signer = Aws::S3::Presigner.new
  url = signer.presigned_url(:put_object, 
    bucket: 'my-bucket', 
    key: "uploads/#{current_user.id}/#{SecureRandom.uuid}",
    expires_in: 3600
  )
  render json: { url: url }
end

This approach minimizes the exposure of long-lived credentials and ties access directly to the authenticated user’s context, aligning DynamoDB-related operations with secure, least-privilege principles.

4. MiddleBrick integrations for ongoing validation

Use the middleBrick CLI to validate that your endpoints do not leak data across origins and that DynamoDB-related responses do not expose sensitive details. Run middlebrick scan <url> to test your API from the terminal and integrate the GitHub Action to fail builds if security scores drop. For continuous monitoring, the Pro plan provides scheduled scans and alerts, helping you detect regressions in CORS and authorization logic over time.