WriteFreely is not CSP friendly

[Crocmagnon]

Describe the bug

A strict Content-Security-Policy looks like this:

Content-Security-Policy: default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'

This prevents execution of inline scripts and styles which WriteFreely uses.

Steps to reproduce (if necessary)

1. Setup writefreely
2. Add custom CSS
3. Configure the webserver (nginx/apache/...) to serve a Content-Security-Policy with the value default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'; font-src 'self' (added the font-src)
4. Observe things that don't load in the browser dev console
   a. Custom CSS doesn't load because it's inline
   b. Some scripts don't load because they're inline

Expected behavior

WriteFreely should be CSP-friendly and fully work with a strict CSP enabled. This would reduce attack surface for things like XSS.

Workaround

We currently have to include unsafe-inline in the styles and script sources which is considered unsafe by organizations like Mozilla.

Content-Security-Policy: default-src 'none'; img-src https:; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; font-src 'self'; connect-src 'self'

• font-src is required to load fonts
• connect-src is required to publish drafts and posts at least

Application configuration

• Single mode or Multi-user mode? single
• Database? [mysql/sqlite] sqlite
• Open registration? [yes/no] no
• Federation enabled? [yes/no] yes

Version or last commit: v0.12.0-2-g037fc40

[Crocmagnon]

I suggest:

1. Serving the custom CSS on an endpoint retrieving data from the DB instead of rendering it inline.
2. Extract the inline Javascript to a separate file.

Note: that goes against other recommendations of reducing the number of HTTP requests for the sake of performance.

[gordon-shumway-net]

Hey together,
I agree with Crocmagnon and would like to see improvements in regard to being more CSP friendly.
One way of doing that and keep the inline scripts would be maybe to use "hash-source" and as described on blog.mozilla.org[0]
and document these Hashes somewhere. This might be not the best option as this hashes might change with newer Versions of Writefreely, it's more complicated to configure that and the correctness of the hashes need to be validated, but actually this applies to the whole software code so it's not a problem specific to the inline-javascript hashes.

What do people from Writefreely think about that Issue?

Gordon :)

[0]https://blog.mozilla.org/security/2014/10/04/csp-for-the-web-we-have/

[Crocmagnon]

Another idea might be for writefreely to serve its own CSP header, so serving hashes could be possible.

[gordon-shumway-net]

And by the way, in regard to the performance problem when extracting the inline Javascript to a separate file it can be maybe also a solution to serve Content via HTTP/2 which is multiplexing multiple HTTP Requests into one TCP Connection.

[thebaer]

Thanks for starting the discussion on this, @Crocmagnon. I think the "hash-source" method @gordon-shumway-net mentioned could definitely work for us, without involving a ton of extra work. But I think for us to do this well, we'll need to make it configurable, to allow a range of uses from: doesn't matter to minimally customized to fully customized. I think there are also two sides to this: the author / admin side and the reader side. The admin side should be simpler to protect, but the reader side will need to e.g. allow different external scripts, etc.

Since this is more of an involved improvement, I think we need to scope out the work, figure out how we'll make it configurable, and then find developers who would be interested in building this. So I'll close this as a bug report and move it to a discussion.

[thebaer]

Actually, GitHub discussions doesn't seem to work the way I'd like, so we'll move this discussion to our forum, like usual: https://discuss.write.as/t/content-security-policy-csp-support/3026