feat: implement wildcard support for cors origins option

[scottenock]

What's Changed

• Implemented support for wildcard origins
• no breaking change

Example

When configuring the cors middleware, it is now possible to provide a wildcard origin to the origins array:

  handler.use(
    cors({
      disableBeforePreflightResponse: false,
      origins: ['https://example.com', 'https://*.example.com']
    })
  )

A request from a sub-domain (https://example-subdomain.example.com) would then result in a header that matches the subdomain:

 'Access-Control-Allow-Origin': 'https://subdomain.example.com',

Notes

Hey @willfarrell , I'm proposing this change be added to the project. This change will allow user's to pass wildcard origins to the middleware. This will make it easier to administer cors headers when traffic is coming from multiple different sub-domains.

Please let me know your thoughts! It's been fun working on the codebase 🥳

[willfarrell]

Thanks for the PR! I see this adding value from a developer stand point, but I worry from a security standpoint.

Allowing all subdomains is a great use case of this feature, but I can see the . making a subdomain being missed (we're all human). In this case it would work for all subdomains but also any other domain that ends with your domain. These kinds of domains are typically purchased by attacks for phishing attacks. This is hard to test for or even detect with SAST.

How many subdomains do you have?

[scottenock]

MDM recommended regular expression escaping.

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions#escaping

FYI - There is an ECMAScript proposal to add such a function to RegExp.

[scottenock]

Hey @willfarrell , thanks for the feedback. I have adjusted the code and implemented a more robust regex escape for the origins.

I have also limited the wildcard to match one level of subdomains. Meaning the allowed origins will need to provide the specificity of nested subdomains:

https://*.*.example.com -> https://nested.subdomain.example.com (match)
https://*.static.example.com -> https://anything.static.example.com (match)
https://*.example.com -> https://nested.subdomain.example.com (reject)

Example

  handler.use(
    cors({
      disableBeforePreflightResponse: false,
      origins: ['https://example.com', 'https://*.example.com']
    })
  )

A request from a sub-domain (https://example-subdomain.example.com) would result in a header that matches the subdomain:

 'Access-Control-Allow-Origin': 'https://subdomain.example.com',

However, a request from a nested-subdomain (https://nested.example-subdomain.example.com) would result in a Access-Control-Allow-Origin header not being set.

Security Implications

Regarding the security concerns you have highlighted:

this case it would work for all subdomains but also any other domain that ends with your domain. These kinds of domains are typically purchased by attacks for phishing attacks.

If I'm correct in understanding your point, you have concerns that by allowing users to use wildcards they may unintentionally whitelist a domain that is being used for phishing attacks.

Example:

The user has set their origins to: ['https://*example.com']. This will whitelist all domains that end with example.com. Which might not be what the user has intended.

In this situation a hypothetical phishing site hosted at phishingattackexample.com would become whitelisted.

This risk stems from a misconfiguration of the origins, and to me seems like user error. A properly configured origins property would be: ['https://*.example.com'] which would whitelist all subdomains of example.com

Thoughts:

I have a few thoughts regarding this:

1. The existing behaviour of this middleware is to default the origin to be * which will whitelist all domains (phishing sites included), so this security implication already exists.
2. In the above example, it is possible that the user's intention was to whitelist all domains that end with example.com and we should give them the tools to accomplish this if they desire.
3. This behaviour is present within other popular CORS middleware. For instance the CORS middleware for ExpressJS takes in a regex pattern (docs)

RegExp - set origin to a regular expression pattern which will be used to test the request origin. If it’s a match, the request origin will be reflected. For example the pattern /example.com$/ will reflect any request that is coming from an origin ending with “example.com”.

NOTE: Interestingly in their documentation for the RegExp pattern, they list this exact use case where a user may configure the middleware to match all origins ending with example.com

Very interested to hear your thoughts regarding this. My view is that the risk would be attributed to user error and not the middleware wildcard functionality itself.

Having researched the above points, I would also be interested and happy to aligning this implementation to the way the ExpressJS CORS middleware works. Taking in a RegExp instead of a string containing wildcard values.

[willfarrell]

Thanks for the detailed write up, apologies on the delay. I plan to merge this in and release with performance tweaks. Might be another week still, thank for you patience on this.

Note: we plan to change the default origin to null in the next major release.