resource-timing
resource-timing copied to clipboard
w3c
Allow semi-wildcard `Timing-Allow-Origin` values (for subdomains)
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.
Needs a careful security/privacy review. If those can be resolved, this seems like useful syntactic sugar.
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?
