NO_CORS_HEADERS

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.

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

• OWASP: HTML5 Security Cheat Sheet - Cross Origin Resource Sharing
• OWASP: Web Security Testing Guide - Testing Cross Origin Resource Sharing
• OWASP: CORS OriginHeaderScrutiny

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.