Cors Wildcard in Sails with Dynamodb

A CORS wildcard (Access-Control-Allow-Origin: *) in a Sails.js application that uses DynamoDB as a persistence layer can expose both data and configuration when credentials or custom headers are involved. Sails, by default, can reflect the incoming Origin header into Access-Control-Allow-Origin. When configured with a wildcard while also allowing credentials (e.g., cookies or authorization headers), browsers block the response, but server-side requests may still expose sensitive data if the application logic does not validate origins.

In a DynamoDB-backed Sails app, this often manifests in two ways. First, if the API returns sensitive DynamoDB records and the frontend runs in a browser, a wildcard allows unauthorized origins to read responses when credentials are not required. Second, if the Sails app makes server-side calls to DynamoDB using temporary credentials (e.g., from an assumed role), a wildcard can allow a malicious site to trigger those calls via CORS-enabled requests, leading to over-privileged data access.

Consider an endpoint /api/records/:id in Sails that fetches an item from DynamoDB using the AWS SDK. If CORS is set to * and the route does not validate the origin or scope the access to the specific caller, an attacker can craft a webpage that invokes this endpoint. Even if cookies are not sent, the response may contain data that should be restricted. The wildcard does not cause DynamoDB to misbehave, but it removes a layer of enforcement that would otherwise limit which origins receive sensitive query results.

Additionally, preflight requests (OPTIONS) with a wildcard can reveal which headers and methods the Sails backend supports, aiding reconnaissance. If the Sails app uses the cors hook with broad settings, an attacker can enumerate allowed methods and headers without authentication. Combined with DynamoDB operations that return large datasets, this can expose data models and potentially sensitive attributes.

For compliance mappings, a CORS wildcard in this context aligns with OWASP API Security Top 10 controls around authentication and authorization enforcement. It does not directly violate PCI-DSS, SOC2, HIPAA, or GDPR by itself, but it weakens access controls that those frameworks expect to be enforced through proper origin validation.

Remediation focuses on tightening CORS configuration and ensuring DynamoDB access is scoped per request. In Sails, use the cors hook configuration to avoid wildcards and explicitly define allowed origins, methods, and headers. Combine this with server-side validation of the requester’s scope before issuing DynamoDB calls.

First, configure CORS with specific origins instead of *. In config/cors.js, set origins explicitly and avoid credentials when not needed:

module.exports.cors = {
  origin: ['https://app.example.com', 'https://admin.example.com'],
  credentials: true,
  exposedHeaders: [],
  maxAge: 3600,
  routes: ['GET', 'POST', 'PUT', 'DELETE']
};

If credentials are not required, set credentials: false to reduce risk. When credentials are necessary, ensure that the origin list is minimal and that each origin is authenticated and authorized at the application level before any DynamoDB interaction.

Second, scope DynamoDB requests with condition checks and IAM-bound principals. In your Sails model or service, use the AWS SDK with a scoped operation. For example, when retrieving an item by ID, verify that the requester is allowed to access that item, and use a condition expression to enforce ownership or tenant boundaries:

const AWS = require('aws-sdk');
const dynamo = new AWS.DynamoDB.DocumentClient({ region: 'us-east-1' });

module.exports = {
  async findOne(id, userTenant) {
    const params = {
      TableName: 'Records',
      Key: { id },
      FilterExpression: 'tenantId = :tid',
      ExpressionAttributeValues: { ':tid': userTenant }
    };
    const result = await dynamo.get(params).promise();
    return result.Item;
  }
};

This ensures that even if a request reaches the Sails route, the DynamoDB call enforces tenant isolation. Do not rely on CORS alone for data isolation; use application-level checks and condition expressions.

Third, validate and sanitize inputs before using them in DynamoDB queries. In Sails, use policies to inspect parameters and headers:

// api/policies/require-origin-check.js
module.exports = function (req, res, next) {
  const allowedOrigin = 'https://app.example.com';
  const requestOrigin = req.headers.origin;
  if (requestOrigin !== allowedOrigin) {
    return res.forbidden({ error: 'CORS origin not allowed' });
  }
  return next();
};

// In a route definition
module.exports.routes = {
  'GET /api/records/:id': {
    policy: 'require-origin-check',
    controller: 'RecordController',
    action: 'findOne'
  }
};

With these measures, the Sails app aligns with secure practices, reducing the attack surface associated with a CORS wildcard while maintaining controlled access to DynamoDB resources.