Open 007 opened 6 years ago
Or I suppose copy cookies and accept a leading dot as a "domain" match: ".example.com"
We'd have to investigate what current browsers do when they encounter that. Hopefully they ignore it, but worst case they might throw an error and ignore the entire CSP. That would be an argument in favor of expanding the scope of "*.example.com", although that risks opening up a bypass for sites that explicitly do not want to allow content from the bare domain. Does that happen?
People might already want some kind of a negation syntax ("*.example.com but not partner.example.com or vendor.example.com") and this would make it more important. A leading hyphen seems obvious since a domain isn't supposed to start with one (but I bet they exist nonetheless).
(Please close https://github.com/w3c/webappsec/issues/513 if this is the more appropriate forum for the request)
As it stands, it seems that I need to explicitly add
example.com
andcdn.example.com
as separate entries in CSP headers. Any subsequent subdomains could use*.example.com
for matching, but the*.
prefix doesn't match a domain with no prefix.I'm not sure the exact fix, but I'd like to see the preceding
.
as implicit for bare domains, sort of like the trailing dot is part of the SOA / zone records in DNS. That would let the*.example.com
match both the bare domain and any subdomains, without requiring two separate rules to implement.*example.com
would work too, but only if the implicit-dot is part of the parser. If not,evilexample.com
would be a terrible security hole.