Cors Wildcard in Grape with Dynamodb

A CORS wildcard (Access-Control-Allow-Origin: *) in a Grape API that directly integrates with Amazon DynamoDB can unintentionally expose sensitive data and amplify authorization flaws. When the wildcard is used indiscriminately, any origin can make requests to the endpoint, and if the route relies on dynamic parameters to query DynamoDB without proper ownership checks, it may return data belonging to other users.

Consider a typical pattern where a Grape route uses a path parameter such as id to fetch an item from a DynamoDB table:

class ItemsEndpoint < Grape::API
  format :json

  get '/items/:id' do
    client = Aws::DynamoDB::Client.new(region: 'us-east-1')
    resp = client.get_item(table_name: 'Items', key: { id: { s: params[:id] } })
    present resp.item
  end
end

If this endpoint sets headers['Access-Control-Allow-Origin'] = '*', any website can send a request with any id. Because the code does not validate that the authenticated subject owns the item, an attacker can iterate over IDs or guess valid keys and read data they should not see. This becomes particularly risky when the DynamoDB item contains PII, financial details, or secrets, as the wildcard allows any external page to embed a script that silently collects responses via JavaScript.

Moreover, a wildcard combined with complex DynamoDB query patterns can expose relationships in the data. For example, if the frontend relies on filtering client-side, the server may return a larger dataset than intended, and the wildcard ensures that leaked information is accessible to any malicious site. In a scenario where preflight requests are not strictly limited, the browser may send OPTIONS checks that confirm the endpoint is open to all origins, making enumeration easier for an attacker.

Another subtle risk arises when credentials are passed from a browser to the Grape service. If the frontend uses AWS SDKs with temporary credentials and the backend also uses a wildcard, the effective trust boundary blurs. An attacker who can make cross-origin requests might chain CORS misconfiguration with SSRF or confused deputy issues, especially if the backend forwards headers to DynamoDB without strict validation. This can lead to privilege escalation when the assumed identity has broader permissions than necessary.

In summary, the combination of a CORS wildcard and DynamoDB access in Grape creates a situation where data exposure is not due to DynamoDB itself being misconfigured, but because the API surface does not enforce origin restrictions and ownership checks. The wildcard removes a layer of network-level isolation, allowing any external page to interact with the endpoint and potentially harvest data returned from DynamoDB queries.

To secure a Grape API that queries DynamoDB, replace the wildcard with an explicit origin policy tied to authenticated sessions. The fix involves validating the request source and ensuring that every DynamoDB lookup is constrained by the identity of the caller.

First, enforce a strict CORS configuration that does not use wildcards when credentials or sensitive data are involved. Instead, read the origin from the request and echo it back only if it is allowed:

class SecureItemsEndpoint < Grape::API
  format :json

  helpers do
    def allowed_origin?(origin)
      allowed = ['https://app.example.com', 'https://admin.example.com']
      allowed.include?(origin)
    end
  end

  before do
    origin = request.env['HTTP_ORIGIN']
    if origin && allowed_origin?(origin)
      headers['Access-Control-Allow-Origin'] = origin
      headers['Access-Control-Allow-Methods'] = 'GET, OPTIONS'
      headers['Access-Control-Allow-Headers'] = 'Authorization, Content-Type'
    end
  end

  options '*' do
    {}
  end

Second, bind each DynamoDB query to the authenticated user. If your frontend uses Cognito or another identity provider, map the subject to a partition key or use condition expressions to enforce ownership:

  get '/items/:id' do
    user_id = env['api.user.id']
    client = Aws::DynamoDB::Client.new(region: 'us-east-1')
    resp = client.get_item({
      table_name: 'Items',
      key: { id: { s: params[:id] }, user_id: { s: user_id } },
      consistent_read: true
    })
    error!('Not found', 404) if resp.item.empty?
    present resp.item
  end
end

This pattern ensures that even if an attacker knows an item ID, they cannot retrieve it unless the user_id matches the authenticated subject. The partition key design should align with your access patterns to keep queries efficient and secure.

Third, apply least privilege to the AWS credentials used by the backend. Create an IAM role or user with permissions limited to the specific table and actions needed, such as dynamodb:GetItem and dynamodb:Query, scoped to the user-specific partition key when possible:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Items",
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
        }
      }
    }
  ]
}

Finally, validate and sanitize all inputs before constructing the DynamoDB key. Use strong type checks and avoid concatenating raw strings into key expressions to prevent injection or malformed requests. With these changes, the API can safely serve data without relying on a CORS wildcard, and DynamoDB queries remain tightly coupled to the authenticated user.