2 min read

NO_CORS_HEADERS

Warns when CORS header (or header-like) configuration is detected, requiring that configuration to be allowlisted.
Table of Contents

Conformance is available on Enterprise plans

Misconfiguring CORS (Cross Origin Resource Sharing) headers can introduce security risks, potentially exposing private and/or secure information such as API keys and user data.

This rule is not meant to block usage of CORS. Instead, it is designed to flag potentially risky configuration for review by the appropriate engineer(s) or team(s).

For more information around the risks associated with CORS, including testing for potential vulnerabilities, see:

The examples below are common approaches to settings CORS headers in JavaScript applications. All of these examples will be caught by this rule.

response.headers.set('Access-Control-Allow-Origin', '*');
 
const headers = {
  'Access-Control-Allow-Credentials': true,
};
 
const options = {
  headers: [
    {
      key: 'Access-Control-Max-Age',
      value: 600,
    },
  ],
};
 
const headers = new Headers();
headers.append('Access-Control-Allow-Methods', '*');

Additionally, this rule will catch partial matches, such as a template literal. In this example, the rule will match the "Access-Control-" part of the template literal.

const headers = new Headers();
headers.append(`Access-Control-${HEADER_TYPE}`, '*');

Engineers should reach out to the appropriate engineer(s) or team(s) for a security review of the configuration.

When requesting a review, please provide as much information as possible around the proposed CORS configuration. Where applicable, include information around alternative approaches, and why this approach is preferable.

As there are many ways to configure CORS headers in applications, this rule will match any string that looks like a possible CORS header. We've tried to mitigate the risk of false-positives, but if they occur they will need to be added to the allowlists.

Last updated on June 20, 2024