Content Security Policy?


I’ve recently been trying to implement a Content Security Policy header on my site. USo far the only policy I’ve been able to get to work is one that includes “unsafe-inline” scripts. Is this something that is potentially solvable through configuration to make more strict?

Here’s what I’ve gotten going
default-src ‘none’; connect-src ‘self’; img-src ‘self’ data:; script-src ‘self’ ‘unsafe-inline’; style-src ‘self’ ‘unsafe-inline’

Recommended HTTP Headers

e: Original post quoted for easier reference.


Thank you for the note. I do appreciate the commentary in the old post. I get the point of the CSP, but based on your reply, screw csp (for tt-rss).


Security is done in layers. CSP is a layer. You’re not going to suffer without it using a well-designed site but it certainly is nice to have. I build my sites now with CSP in mind and try to grant only what’s necessary.

Nevertheless, fox is right in that script elements are removed (both HTML tags and inline) from subscribed content. I have yet to see the current filter circumvented, but if someone finds a way, by all means notify fox responsibly so it can be addressed in an update.

Keep in mind that the only content you’re seeing is content you subscribe to. While there should be a measure of trust here we cannot be certain a site is not hacked so there is a sanitize method that cleans the content.

There are so many attack vectors these days I’m not sure CSP would even be enough (but again, it’s not an all-inclusive measure but rather a layer). I’ve seen carefully crafted images trigger arbitrary code execution in browsers; certainly CSP wouldn’t stop that. Probably for TT-RSS users the biggest thing is JavaScript and as near as I can tell, that is properly removed.

You can add a CSP policy. I would do it in the web server conf files along with the cross-origin, sniffing, etc. headers. With TT-RSS you are going to have to make it somewhat relaxed because of the way it has been designed.


Frankly, with what TT-RSS does for tags & scripting already I’m happy it was my Google Reader replacement. Nothing is ever perfect, but knowing that the development of this is done with security at least thought of is nice. It does play well with all my other tags (apache)

Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
Header set X-Content-Type-Options nosniff
Header set X-XSS-Protection: "1; mode=block"
Header set X-Robots-Tag: none
Header set X-Frame-Options: SAMEORIGIN
Header set Referrer-Policy: no-referrer


There is benefit to using CSP, for sure.

That being said, the largest threat is execution of JavaScript, which is stripped from the source content anyway. A CSP policy that limits JavaScript to self and prevents unsafe-inline would undoubtably make things more secure but would also break TT-RSS’s UI; so unsafe-inline would have to be allowed, which then brings us right back to square one: the largest threat.

It is my opinion that things like CSP should be handled at the web server level (e.g. Nginx, Apache, etc.). Leave the application layer out of picture to further separate things and make compromising more difficult (e.g. if someone managed to get PHP code to run they could just modify the CSP header anyway; whereas if it’s in the Nginx conf file, they’d have to compromise another application, which makes things more complex). This brings us to the real point: You can just add a CSP header yourself in your web server.


i’m not adding placebo headers in case a sudden exploit in libxml would prevent proper sanitization or any other equally unlikely apocalyptic scenarios

oh boy, another condescending sperg is here to show us the light of CSP, again.


And yet, here you are, harping into the wind.