I have my TTRSS instance up and running (and it is great ) ), but I would like to work on the web server configuration to follow the best practices.
As I understand it, there is several additionnal HTTP headers that can lower the likeliness of your site or your users being targeted by attackers.
However, if I understand things correctly, some of these “secure headers” would break ttrss. (like Content Security Policy other than unsafe-inline, if I understood that thread correctly).
So, what do you use for your web server settings for ttrss, or what would you recommend ?
(I use those so far :
Header always set X-XSS-Protection "1; mode=block"
Header always set Strict-Transport-Security "max-age=31536000; includeSubdomains"
Header always set X-Content-Type-Options "nosniff"
Header always unset "X-Powered-By"
Header unset "X-Powered-By"
Header always set X-Frame-Options SAMEORIGIN
Header always set Content-Security-Policy "unsafe-inline"
Thanks a lot.
P.S. : Another thing on headers : should I modify the Content-Type for generated feeds to be RSS specific (like application/rss+xml or something ?
how is this related to tt-rss? i’m sure there’s plenty of places more fit to discuss placebo approach to security.
I was thinking some of those setting could be harmful to ttrss functionalities, specifically those related to the source of the content, since the base idea of an RSS reader is to embed external sources. I did not find a discussion about what settings should be applied for that type of application, hence I asked the question here.
Does these headers provide no advantage at all on the client side ?
I get that it does not make my installation or my server more secure (Disabling X-Powered-By is merely obscurity), but I was more concerned by the client side, and preventing potential attacks on the user session, and other things of that sort.
Do you think that is simply a waste of time ?
except for HSTS and maybe denying frames (very questionable) yes its a placebo and a waste of time + you will break tt-rss with unsafe-inline.
headers are not going to save you from shitty software like wordpress. don’t rely on bandaids like above and especially stuff like x-powered-by (which is seriously stupid, people will easily fingerprint your shitty apache even if you don’t provide the header, duh).
what would actually help is using ssl with proper certificates and (on server side) properly setup open_basedir. or docker, i guess.
personally these days i put almost everything third party into docker. then again i guess it’s a bit hypocritical to recommend it for tt-rss because i don’t support third party docker images. :shrug:
Always: Strict-Transport-Security and Public-Key-Pins.
Usually (I genuinely question the usefulness of these, but people recommend them and it’s easy to add): X-Frame-Options, X-XSS-Protection, X-Content-Type-Options
Sometimes: Content-Security-Policy. If it’s not going to break things. It’s the type of thing that, with third-party applications, can require some trial and error before getting it right; most of the time I don’t have patience for it (like Apache’s mod_security, it’s a nice idea but sometimes difficult to get just right). If I make the application myself then I use it because I know what’s required.
I do not hide the applications I’m using (Nginx, PHP, TT-RSS, etc.) because most attacks are automated and will just try the attack regardless of what’s on the server (seriously, have you ever looked through your logs? The attacks are varied and unending). I do hide version numbers because that’s an option in PHP-FPM and Nginx, so why not? But it’s not going to make any difference.
At any rate, OP, you have the right idea, but remember these headers are typically there to protect the person using the web site in the event that some content delivered by the server is compromised (bad ad provider, compromised server, etc.). They do not protect the server itself from anything.
Also, much of the syntax you’ve used is wrong and that will result in the headers either being ignored (defeating the purpose) or the browser freaking out and refusing to allow you to use the web site at all.
Just do what fox said: Setup proper SSL and then use a site like Qualys SSL Labs to double-check your SSL configuration. Once that’s done you can optionally set Strict-Transport-Security.
On the server side, that’s done. Ttrss is running in a docker container (the Dockerfile is not that complicated to write, and even then there is some out there already), in an openshift cluster, behind an HAProxy (which took cares of the SSL part with wildcard certificate covering the subdomain on which ttrss is served.
That is precisely my intention, protect the user
Could you point me to the error ? While testing on a local docker, the headers seemed to be sent appropriately, (testing with curl -I).
Anyway, thanks all for your inputs. I’m going to put only the headers with a purpose I have clearly understood, and the others will wait.
Anyway, drop the X-Powered stuff and for the content security policy make sure its value is correct. See this site for details.
FWIW, I don’t use CSP with TT-RSS. I think limiting javascript is the single biggest thing you can do to improve security and doing that breaks the application. Plus TT-RSS strips third-party javascript anyway.
) ), but I would like to work on the web server configuration to follow the best practices.
