Can we tighten up our CSP?

[alexgibson]

Description

https://observatory.mozilla.org/analyze/www.mozilla.org

We currently allow both unsafe-inline and unsafe-eval in script-src, but I'm not 100% sure if anything we're using today is relying on those?

Might we also be able to remove unsafe-inline from style-src?

Possible things to check:

• Webpack might use eval() but only in dev mode. In prod mode it should not be needed.
• Convert is still a thing on our site for A/B testing, but has not been used for a long time?
• Does GA/GTM require any of the above? Not to my knowledge, but worth checking.

---

Success Criteria

• We get an improved score for CSP in Mozilla Observatory.

Tasks

Beta Give feedback

1. Enable CSP violation reporting for a small proportion of visits #14451
   Backend +1
   
2. Consider using frame-ancestors for clickjacking control #14835
   +0
3. Remove unsafe-eval & unsafe-inline from script-src #14828
   +0
4. Remove unsafe-inline from style-src #14840
   +0
5. Set default-src 'none' and set individual directives explicitly
6. Investigate adding base-uri
7. Investigate adding form-action

[alexgibson]

Same also applies for Pocket mode ^

[alexgibson]

GTM CSP guidelines for future reference: https://developers.google.com/tag-platform/security/guides/csp

[alexgibson]

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1882733

[janbrasna]

After CSP reporting is in place #14453, is there a chance to add another, more restrictive policy header, as Content-Security-Policy-Report-Only e.g. without the unsafe inlines, to let the usual traffic help identifying places that might be still using these? Can django-csp send both "real" and CSP_REPORT_ONLY, or it's either-or but not both?

[stevejalim]

Ah, @janbrasna I think you just stumbled across the one thing we need to add to django-csp before we can ask the Django project to fold it into core mozilla/django-csp#36

[janbrasna]

@stevejalim 🤦 gotcha, next time I need to utfg, this time I only rtfd and didn't look further;)

To update the original post:

• "webpack-dev-server": "^5.0.4" should not require any eval()s 5.0 dev server requires 'unsafe-eval' script-src in CSP webpack/webpack-dev-server#5044 CSP WebSocket.client.onmessage webpack/webpack-dev-server#3062
• Convert has been recently removed: Remove Convert integration (Fix #14039) #14044
• GA/GTM doesn't need any unsafes, recommended settings: Use Google's recommended CSP for Google Analytics #14082

(I still can't seem to get to the bottom of the local dev webpack websockets and whether that would need adding to connect-src for dev extras… but investigating why the ws: is not covered by self in the first place…)

I think the quick win in the ratings is also to disallow object-src completely if it's not used anywhere.

[robhudson]

Just to add here, the latest beta release of django-csp will allow adding a report-only CSP. As @janbrasna pointed out above, we could enable that without the unsafe-inline and/or unsafe-eval and see what's tripping it.

[janbrasna]

The last inlined style was removed in #14614 and I couldn't find any more of such occurrences so hopefully the unsafes can be gone soon.

Also disabling object-src completely should be possible.

[janbrasna]

Just adding one piece of the puzzle that hasn't been mentioned before I guess — when tightening the individual policies instead of appending the defaults everywhere eventually, a reasonable set of hosts should be picked for every rule, as wildcards can basically mean stuff can get linked from addons.m.o, support.m.o and similar "user generated content":

So e.g. tighten *.mozilla.net to assets.mozilla.net for images and code.cdn.mozilla.net for fonts etc. (effectively not allowing e.g. interactive-examples.mdn.mozilla.net content via wildcards…); explore what mozorg subdomains besides www.m.o need to have stuff hotlinked from and constrain the wildcard etc. …