12

I have a REST API exposed to the Internet and another application with form-based authentication. These apps are behind a Web Application Firewall.

Question is, where I should implement the below security HTTP headers, in the WAF or at the code level?

  • X-XSS-Protection
  • X-Frame-Options
  • X-Content-Type-Options
  • X-Permitted-Cross-Domain-Policies
  • HTTP Strict Transport Security
  • HTTP Public Key Pinning
  • Content Security Policy
  • Referrer Policy
  • Feature-Policy

Second question: What if the header is configured on code level and as well on WAF level? I will get header twice, but is it wrong?

  • HTTP Public key Pinning is no longer supported by any major browser, as it effectively renders your website unusable should you do any mistake. – MechMK1 Jan 21 at 14:48
  • Some details ^ on Public-Key-Pins deprecation. – msanford Jan 22 at 14:34
19

From the perspective of the client, it does not matter where these headers are implemented; only whether they are implemented at all.

But, from the perspective of deployment, a WAF should be treated only as an additional line of defense and not as the single line of defense. This means that proper input checking should be done in the web application itself and proper setting of security headers too, at least for most of the headers: HPKP can of course only be set on the TLS endpoint owning the certificates which might be the WAF (if it should be set at all since it is deprecated).

Setting the security headers in the web application itself is also better from a development perspective. As much as developers should know what the expected type of specific inputs is and how they should be checked, the developers also know about how the application works and what for example the tightest Content-Security-Policy can be. A WAF is instead often deployed by a different team which does not have deep knowledge of the application and therefore cannot easily set the security headers to the tightest values acceptable by the application.

Therefore it should only be set in the WAF if it cannot be set in the application itself, which might be the case with third-party applications. As an additional line of defense, though, a WAF may still be used to ensure that the headers are there and sufficiently strict, since it might be that the developers forgot to set them.

| improve this answer | |
5

Just for some thoughts, without saying this is a proper recommendation:

  • Check which levels of flexibility you need - if some of these headers need to be set in special circumstances (eg. depending on the state of your application), you maybe have no chance but to keep them in the application.
  • If there are multiple apps behind the WAF, can you be sure that all of them need the same set of rules? Conditional rules might be more difficult to implement than general ones
  • Do you want to keep your rules under source control (which could log who implemented which rules when)? Then they should be part of your application, not of an additional layer

If you don't want to mix the configuration (as in: set some headers here, some there), keep them in your application

| improve this answer | |
  • 2
    Welcome Nico, this is a very helpful first answer! I made a change and inverted one of your statements in your first point. I suspect that you forgot a "not" and accidentally said the opposite of what you meant, but I want to bring my change to your attention in case I misunderstood you and edited it incorrectly. – Conor Mancone Jan 20 at 20:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.