|
|
|
|
|
by niftich
3491 days ago
|
|
Security headers are worthy of a different [1], lengthy conversation, but they were borne out of need to override defaults about a browser's security features. Sometimes, for different features, those defaults are permissive, and sometimes they're restrictive, provided the browser supports that header -- and most of them were designed to be backward-compatible so that their truth tables are complicated. But realistically, consider C-S-P as metadata about the resource representation about to be delivered in the body, instead of a property of the HTTP response itself. In fact, the naming of the header 'Content-[...]' is consistent with the semantics of RFC 7231 [2] which defines a number of different 'Content-[...]' headers, like 'Content-Type' and 'Content-Language'. You can mentally move C-S-P from the HTTP headers into a meta tag (you can do this actually [3]). [1] https://hn.algolia.com/?query=niftich%20"damn%20header"&type...
[2] https://tools.ietf.org/html/rfc7231#section-3.1
[3] https://w3c.github.io/webappsec-csp/#meta-element |
|