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?

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

2 Answers 2

Reset to default
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
1
  • 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
    Commented Jan 20, 2020 at 20:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .