You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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:
*
either for security reasons.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.The text was updated successfully, but these errors were encountered: