stricter Content-Security-Policy

[bagder]

Site analyzers will tell us the Content-Security-Policy on curl.se is too lax.

I can't understand CSP, but we should see how we can clean it up. If anyone can figure it out.

[dfandrich]

I'm guessing the main problem is the unsafe-inline. This is a bit of a pain to get rid of since it mean removing all style="…" elements from the HTML (the sha256- hash workaround is even more painful). Given that there is practically no Javascript anywhere on the site, there's not a lot of benefit to doing this. We could try eliminating it from the pages that do use Javascript and serve a tighter CSP there. There are only two such pages that I can think of (that aren't password-protected): https://curl.se/dev/builds.html and https://curl.se/search.html, so this shouldn't be too bad.

[vszakats]

Here's most that I use (all security headers, not just CSP):

add_header Alt-Svc 'h3=":443"; ma=86400' always;
add_header Cache-Control 'max-age=3600, must-revalidate';
add_header Content-Security-Policy "upgrade-insecure-requests; block-all-mixed-content; default-src 'none'; manifest-src 'self'; frame-ancestors 'none'; form-action 'none'; base-uri 'self'; img-src 'self' data:; style-src 'self'; script-src 'self'; media-src 'self';" always;
add_header Cross-Origin-Embedder-Policy 'require-corp';
add_header Cross-Origin-Opener-Policy 'same-origin';
add_header Cross-Origin-Resource-Policy 'same-origin';
add_header Permissions-Policy "accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), bluetooth=(), browsing-topics=(), camera=(), display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(), fullscreen=(), gamepad=(), geolocation=(), gyroscope=(), hid=(), identity-credentials-get=(), idle-detection=(), local-fonts=(), magnetometer=(), microphone=(), midi=(), otp-credentials=(), payment=(), picture-in-picture=(), publickey-credentials-create=(), publickey-credentials-get=(), screen-wake-lock=(), serial=(), speaker-selection=(), storage-access=(), usb=(), web-share=(), window-management=(), xr-spatial-tracking=()";
add_header Referrer-Policy no-referrer;
# Requires adding to the global preload db at https://hstspreload.org/:
add_header Strict-Transport-Security 'max-age=63072000; includeSubDomains; preload';
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options deny;
add_header X-Permitted-Cross-Domain-Policies master-only;
add_header X-XSS-Protection '1; mode=block';

Agree it'd be nice to avoid unsafe-inline for CSS, and JS.
It can be tricky at times.

[bagder]

This update made the Mozilla observer report happier and now also the CSP section is green:

see here

[vszakats]

https://securityheaders.com/?q=curl.se&followRedirects=on is flagging these two:

• Referrer Policy is a new header that allows a site to control how much information the browser includes with navigations away from a document and should be set by all sites.
• Permissions Policy is a new header that allows a site to control which features and APIs can be used in the browser.

[dfandrich]

We serve four different CSP headers on the site now, but all but one of them are pretty tight now, including the default which is what those analyzers are looking at. The one at https://curl.se/search.html is looser because the Google search box needs it to be. Getting rid of style 'unsafe-eval' in the default CSP means removing hundreds of style= instances scattered about the HTML, which I'm not sure is worth it.

Adding some of Victor's headers should be pretty safe and easy. Do we want to block curl.se from showing up in somebody's <frame>?

[vszakats]

After #574, securityheaders.com reports A+ (up from A).

[bagder]

Now we can't run the site on curl.local anymore though (it won't use the CSS) which seems like a rather annoying regression...

[bagder]

Hm, it might even be more than the CSS as for example http://curl.local/libcurl/c/libcurl.html is now downright refused to be shown by Firefox.

[vszakats]

Is it because of http://? I use self-signed localhost certs locally. Since then, there is mkcert to make this easy: https://github.com/FiloSottile/mkcert
There may be other solutions to patch out problematic headers locally, but haven't explored this, esp with Apache (I use nginx).

[bagder]

Is it because of http://?

Ah yes it is. Since we use unconditional redirect to HTTPS:// and HSTS on the server do we really need upgrade-insecure-requests; block-all-mixed-content; in the CSP? That's what makes doing local serving on HTTP impossible.