Cors Wildcard in Sails with Api Keys

A CORS wildcard (origin: *) combined with API key authentication in a Sails.js application can unintentionally expose privileged endpoints to any website. When cors.allRoutes is set to true with origin: '*' and credentials are enabled, browsers include cookies or authorization headers across origins, allowing a malicious site to make authenticated requests on behalf of a user who has an API key stored in client-side JavaScript.

API keys are often passed in headers such as x-api-key. If a Sails app validates the key but still responds to cross-origin requests via a wildcard, an attacker can embed the target endpoint in a frontend script and harvest keys or data. This situation violates the principle that authentication mechanisms should reduce the attack surface exposed to untrusted origins. The combination is especially risky when the API key has broad permissions, because the key is effectively leaked to any site that can execute JavaScript in the victim’s browser.

During a middleBrick scan, which tests the unauthenticated attack surface in 5–15 seconds, such misconfigurations appear in the CORS and Authentication checks. The scan correlates the wildcard origin with exposed routes that accept API keys and flags the risk of unauthorized cross-origin access. This maps to the OWASP API Top 10 controls for security misconfiguration and can be tied to findings under frameworks such as PCI-DSS and SOC2.

An example vulnerable Sails configuration:

// config/cors.js
module.exports.cors = {
  allRoutes: true,
  origin: '*',
  credentials: true
};

An example vulnerable route that relies on an API key header but is reachable from any origin:

// api/controllers/KeyController.js
module.exports = {
  getSecret: function (req, res) {
    const providedKey = req.headers['x-api-key'];
    if (providedKey !== process.env.API_KEY) {
      return res.status(401).send('Invalid key');
    }
    return res.ok({ secret: 'confidential-data' });
  }
};

In this setup, a site under attacker control can load /key/getSecret with XMLHttpRequest or fetch, and if the user’s browser sends the API key via headers or cookies, the attacker can obtain sensitive information. middleBrick’s cross-referencing of the OpenAPI spec with runtime behavior would highlight that a route guarded by an API key still responds to a wildcard CORS policy, providing prioritized remediation guidance.

To secure a Sails application, restrict CORS to known origins and avoid credentials with wildcards when API keys are used. Prefer explicit origin allowlisting and tie authentication to the same-origin policy or use CSRF tokens for state-changing requests. API keys should not be validated in a way that is origin-permissive.

Correct CORS configuration that disables wildcard origins and credentials together:

// config/cors.js
module.exports.cors = {
  allRoutes: true,
  origin: ['https://trusted.example.com', 'https://app.example.com'],
  credentials: false
};

If credentials must be used for a specific route, narrow the origin to exact trusted domains and enforce additional checks within the controller:

// config/cors.js
module.exports.cors = {
  allRoutes: false,
  origin: [
    {
      origin: 'https://trusted.example.com',
      credentials: true
    }
  ]
};

Controller-side validation that checks both the API key and the request origin:

// api/controllers/KeyController.js
const ALLOWED_ORIGIN = 'https://trusted.example.com';

module.exports = {
  getSecret: function (req, res) {
    const origin = req.headers.origin;
    if (origin !== ALLOWED_ORIGIN) {
      return res.status(403).send('CORS policy violation');
    }

    const providedKey = req.headers['x-api-key'];
    if (providedKey !== process.env.API_KEY) {
      return res.status(401).send('Invalid key');
    }

    return res.ok({ secret: 'confidential-data' });
  }
};

For broader protection, use a policy that validates API keys early in the request lifecycle, such as a custom hook or policies/ entry, and ensure that routes requiring keys are not exposed to wildcard origins. middleBrick’s CLI can be used to verify that no route with an API key check has an origin wildcard, and the GitHub Action can enforce that any changes to CORS or authentication settings do not introduce this regression.

When using the middleBrick Pro plan, continuous monitoring can alert you if a future configuration change introduces a wildcard origin on a key-protected endpoint. The dashboard and compliance reports help track security posture over time without assuming automatic remediation.