[💡 FEATURE REQUEST]: HTTP Middleware - Dynamic CORS origin support

[orlandothoeny]

Plugin

HTTP Middleware (any)

I have an idea!

Affected middleware: HTTP

The only thing that prevents us from completely getting rid of our NGINX is CORS support for wildcard subdomains.
The HTTP middleware currently only supports returning static values for the CORS headers.

Use case

We have a PHP API, this API is used by multiple sites that run on the same main domain.

Example

The API is running under api.example.com. We have example.com, cockpit.example.com, admin.example.com and various other sites that all call api.example.com via JavaScript in the browser. Thus, all these hostnames must be allowed as CORS origin.

This also applies to our staging & development environment, which run on the same main domain but under a separate subdomain. E.g. api.dev.example.com, dev.example.com, cockpit.dev.example.com & admin.dev.example.com.

Due to the large volume of hosts and differences between the environments, we decided to use a Regex pattern that allows the main domain, as well as all subdomains below it. This saves us the complexity of having to maintain a separate list of allowed hosts for every environment.

To accomplish this, we use the following NGINX config:

# Allow example.com and all example.com subdomains and sub-subdomains
map $http_origin $allow_origin {
    ~^https://(.*\.)+example.com(:\d+)?$ $http_origin;
    https://example.com https://example.com;
    default "";
}

more_set_headers "Access-Control-Allow-Origin: $allow_origin";

Feature request

HTTP Middleware support that allows us to return the requesting host as allowed_origin value if it is one of these:

• example.com
• Subdomain of example.com
• Sub-subdomain of example.com.
• etc..

Possible implementation ideas

• Regex support. Similar to the NGINX config above. Probably the most flexible?
• Wildcard config. Something like allowed_origin_wildcard: '*.example.com'
• Definition of the main domain, allowing it and all hosts below it: allowed_origin_root: 'example.com'
• ...

Config ideas

Either create a new separate key for the matching-config. Or a new matching-type config.
For example:

1. allowed_origin || allowed_origin_wildcard
   • Probably more complicated because there would have to be a order of precedence?
2. allowed_origin && allowed_origin_type=['simple' || 'regex']

[rustatian]

Hey @orlandothoeny 👋🏻
Oh, this is super detailed feature request, good job 👍🏻 ❤️
The currently available allowed_origin option supports basic wildcards, such as: *.example.com. Is this something that can help you? Until I implement a more advanced version with regexp.

[orlandothoeny]

Hi @rustatian,

Thanks for the quick reply :)

I just saw that the middleware uses https://github.com/rs/cors, I'll have to try that out. In the test-cases I only found one with a simple subdomain, no nested ones: https://github.com/rs/cors/blob/20a76bd635d3c8a7ea58f49fad54b8eecb95aa46/cors_test.go#L116 Maybe it just works. Then nothing would have to change to be able to accomplish this. Except maybe to add this to the docs to prevent future issues.

[orlandothoeny]

I don't know Go, but just by looking at the code I think that should work. I don't see any special subdomain logic. I think it's just a simple wildcard with a prefix + suffix check. So something like allowed_origin: https://*.example.com should work

• https://github.com/rs/cors/blob/20a76bd635d3c8a7ea58f49fad54b8eecb95aa46/cors.go#L179C13-L179C13
• https://github.com/rs/cors/blob/20a76bd635d3c8a7ea58f49fad54b8eecb95aa46/cors.go#L470C11-L470C11
• https://github.com/rs/cors/blob/20a76bd635d3c8a7ea58f49fad54b8eecb95aa46/utils.go#L15

[orlandothoeny]

Just realized that that wouldn't allow https://example.com. And using allowed_origin: https://*example.com would also permit requests from https://i-am-an-evil-hackerman-example.com

[rustatian]

Oh yeah, you're right. Looks like regex pattern matching would be best here. Since I'm able to provide my implementation for the allow logic, it would be possible to use regexp here.
I'll put this FR to the next release, v2023.4 (or v2024). It would be available much sooner as a beta release.