1

I am managing a setup where there are two ngnix application servers behind an nginx reverse proxy. I would like to set some headers like X-XSS-Protection or Strict-Transport-Security. Currently, it's set on both application servers and the load balancer and this is causing headers to be convoluted.

Error parsing header X-XSS-Protection: 1; mode=block, 1; mode=block: expected semicolon at character position 14. The default protections will be applied. 

I can see that the duplicate header values are being appended to the same header key. My question is this: What's the general convention/accepted best practice for setting headers? Should I set headers in the backend and remove them from the load balancer or should the load balancer be the one setting headers?

eternaltyro
  • 262
  • 2
  • 14

3 Answers3

2

In my opinion it doesn't matter where headers are set. The advantage of setting headers in Nginx is they're really quite simple to change, compared with changing code, deploying, etc. I've had two cases where I've had to rewrite headers using either Nginx or an F5 load balancer, they give a lot more flexibility.

You would need to give a more concrete example to get more useful information, as your question is too broad.

Tim
  • 31,888
  • 7
  • 52
  • 78
1

As a developer I would also say take into account development environments.

We only have a load balancer in our production environment and our main preprod environment and the development environments do no have the load balancer in front of them. For this reason I prefer to set the headers in NGinx webservers so they are also set for development environments.

This also depends on whether you terminate HTTPS: on the load balancers or at Nginx or both? For the same reason (keeping environments consistent), and for better security, we terminate HTTPS at the load balancer and then re-encrypt traffic to HTTPS between the load balancers and our webservers so if we connect directly to the webservers they are still served over HTTPS.

If your NGinx webservers are not on HTTPS, then certain headers (HSTS) should of course NOT be set on the webserver, but that obviously introduces questions as to how you can develop and test the impact of these headers when not setting these headers on environments without a load balancer.

Barry Pollard
  • 4,591
  • 15
  • 26
0

Yes, since it's the connection-front-end's job to deal with connections. Your application is busy with it's own thing, best to leave all the resources just to do that. SSL/TLS, common headers, redirects, balancing, blocking, dropping etc. is best handled before it hits the application. It also gives a nice common point for configuration as a bonus.

John Keates
  • 681
  • 4
  • 9