Conversation

Replying to
Safari and Firefox only support CSP hash-source for inline styles and scripts. We avoid inlining since it's far nicer to have them external with 1 year max-age immutable caching + preload header and HTTP/2 push to make it as fast as having them inlined for the first page load.
1
4
CSP has standard support for hash-source with external scripts, but not yet styles since Chromium only cared about adding it for scripts and only requested adding that to the standard. It's unfortunate style support is arbitrarily missing and Firefox/WebKit lack it completely.
1
4
Also makes absolutely no sense that SRI itself is only available for scripts/styles when it should be possible to use it for images, fonts and any other assets that are included. SRI isn't very relevant for us since all the assets are on the same domain (fastest with HTTP/2).
1
3
They decided to base hash-source for external files on SRI so that the CSP implementation only needs to check the SRI hash value and leaves the implementation of enforcing it to the existing SRI feature. Strange that this is so half baked and not a universal feature for assets.
1
3
Our reason for using SRI is simply because we want to use for CSP. It'd be great to have allowlist of each script and style hash compared to using 'self' especially for services with user generated content (Matrix, forums) (Content-Type + nosniff do block using it as such).
1
3
The most important header-based security header we use is this: require-trusted-types-for 'script'; trusted-types 'none'. It enables Trusted Types enforcement and disallows custom sanitizers (none) which almost entirely eliminates XSS as a problem by disallowing APIs causing it.
1
6
Feature isn't available in either Firefox or Safari. They're missing what's easily as important of a security feature as SameSite cookies. It's more important if you actually take full advantage of stuff like Origin and Sec-Fetch-Site (which is of course also missing in Safari).
1
6