CSP
Closed this issue · 4 comments
You should use a restrictive CSP on your site and recommend others to also do so.
@J0WI We hadn't considered CSP here, since it is a static site that doesn't process user input either server-side or client-side. We're also fully HTTPS and HSTS preloaded, so none of the upgrade-insecure-requests directives will help either. What CSP directives might make sense for us?
It doesn't matter if the site is static or dynamic.
I would recommend the following CSP for you, without looking into detail of the site:
Content-Security-Policy "default-src 'none'; style-src 'self'; script-src 'self'; require-sri-for script style; referrer 'no-referrer'; reflected-xss 'block'"
Of course this is very strict and requires you to remove the inline script and add SRI.
A bit less restrictive is this one:
Content-Security-Policy "default-src 'self'; referrer 'origin-when-cross-origin'; plugin-types 'none'; reflected-xss 'block'"
This also requires you to remove inline content from GA (because you should avoid unsafe-inline).
You can optionally add a report-uri to monitor errors.
Since https.cio.gov should be an ideal, I would prefer the most strict variant.
Good references are:
https://developer.mozilla.org/en-US/docs/Web/Security/CSP (detailed guide)
https://securityheaders.io/ (Web GUI for testing)
https://report-uri.io/ (Web GUI for creating CSP and report-uri service)
https://www.w3.org/TR/CSP/ (technical paper)
https://www.w3.org/TR/upgrade-insecure-requests/ (technical paper)
https://www.w3.org/TR/referrer-policy/ (technical paper)
I'm familiar with CSP and CSP reporting, but I still don't understand the value a strict CSP policy would provide to this site.
In any case, https.cio.gov is squarely focused on HTTPS, and not on other security best practices for websites and web services. I totally agree that CSP is related (and we reference CSP policies for mixed content reporting already) but not quite to the extent of recommending or modeling general CSP best practices for other agencies.
I'm going to close this thread, but happy to re-open if folks feel like I'm misjudging the security value a CSP policy would bring to https.cio.gov (which, static or not, doesn't provide any avenues for processing user input beyond pasting content into the developer console).
CSP is no longer just about XSS. The frame-ancestors directive replaces the X-Frame-Options header and prevent click-jacking.
The referrer is also for privacy reasons.
A very strict CSP also can safe you visitors when someone got access to the Git Repo or even the server itself. He would still need root rights on the server to change the CSP header in the servers config. The policy also forces you (and all contributors) to follow your guideline. E.g. it's impossible to just add images to the site without changing the current policy. (Note that also pinned or even preloaded CSP will come in future.)
And last but ot least report-uri can give you interesting facts about your users. E.g. if you suddenly see increasing errors against the plugin-types directive without using any plugins on the site, you know that some users are infected with malware/adware.
Mozilla even use CSP on the built-in sites of Firefox and Firefox OS/B2G to avoid injected content (ads) by third party malware/adware.