Allow semi-wildcard `Timing-Allow-Origin` values (for subdomains)

[jakub-g]

4.5.1 Timing-Allow-Origin Response Header ... If the Timing-Allow-Origin header value list contains a case-sensitive match for the value of the origin of the current document, or a wildcard ("*"), return pass.

With the current state of the art, it's possible to return TAO values like:

• https://www.example.com
• *

It's not possible to specify "semi-wildcard" values to allow subdomains of a given domain, like:

• https://*.example.com

Was this use case ever considered? Are there any reasons to not allow it like this? (it would add a bit more complexity to the spec and implementations, but nothing unreasonable).

A scenario I'm thinking about is:

• my subresources are hosted by a CDN (though I can control the response headers), hence different origin than the website
• I want to allow various subdomains of my domain to opt-in to TAO, including internal ones.
• I do not want to enumerate all internal subdomains explicitly in the header value for security reasons, to not leak too much information about the internal environment.
• I do not want to allow * either for security reasons.
• It's much easier to set static TAO response header than to vary it on a per-response basis.

We could argue that in the CDN scenario with static responses it's probably (most of the time) not a big deal to allow * origins, so maybe the example I made up is a bit artificial. But I still think that in some environments, it might be easier to convince ops people to activate the header on *.mydomain.com than on * -- it would require less analysis from security point of view to have it approved.

[toddreifsteck]

Needs a careful security/privacy review. If those can be resolved, this seems like useful syntactic sugar.

[cvazac]

There seem to be clear use cases for leading (*.example.com) and trailing wildcards (www.example.*). Is there a use case for wildcard somewhere in the middle?