Before diving into some of the key security headers that we can add to our HTTP Request cycles I should draw your attention to a couple of points.

Security headers do not make your website/backend API secure but they are there to make it harder for the attacker to leverage and exploit the vulnerability they have found.

What I mean is that having a green or red checkpoint is not a valid security level indication.

But it is certainly important to have them set since they are helpful to prevent exploitations of attacks such as XSS, clickjacking, etc.

Security Headers

Now let’s review some of the most important security headers that you can implement at the application level or webserver level of products.

X-Frame-Options

Explaining

  • Tell the browser whether your website should be loaded in an iframe or not.
  • The webserver tells the browser not to embed your webpages in frame/iframe if specified.
  • Supported by all major browsers.

Ways to configure it

  1. DENY : Will completely disable iframe features.
  2. SAMEORIGIN : Iframe can only be used on the same origin.
  3. ALLOW-FORM : Iframe can only be used on specific URLs.

Enable in Nginx (In Action)

  • Adding the following line to the Nginx default configuration file (etc/nginx/sites-enabled/your_config_file)

    add_header X-Frame-Options "SAMEORIGIN";

Referrer-Policy

Explaining

  • Referer is a header that indicates where the request was originating from.
    • For example, it could be the Front-End Application making request to your APIs endpoints.
    • But it can also be an external origin, your localhost and etc.
  • Referrer-Policy controls how much referrer information (sent with the Referer header) should be included with requests.
  • Referrer-Policy header is a cool and long topic itself that needs an article itself but to give you an overall idea:
    • Imagine that your site has some functionality that allows users to make requests from your site to another site (x).
    • Now it is important to make sure how much and under which circumstances the originating request URL is received by the site (x).
    • What if the site (x) is not using HTTPS protocol and our URL might contain some sensitive params.
      • Simple Attack in The Middle is enough for our data to be leaked to ISPs, public WIFIs, etc.
    • Or even the site (x) should not receive this kind of information or they receive only our domain.
    • Deeper article: https://web.dev/referrer-best-practices/

Ways to configure it
Lots of ways and should choose based on your goals but two of the best for security and privacy policy

  1. Referrer-Policy: strict-origin
  2. Referrer-Policy: strict-origin-when-cross-origin

Enable in Nginx (In Action)
Adding the following line to the Nginx default configuration file (etc/nginx/sites-enabled/your_config_file)

  • add_header Referrer-Policy "strict-origin";
  • With This, only the origin is sent in the Referer header of cross-origin requests.

X-XSS-Protection

Explaining

  • Also known as “Cross-Site Scripting Header”
  • Enabled by default in modern browsers.
  • It is a header to prevent XSS attack exploitation against websites.
  • Stops pages from loading when they detect reflected XSS attacks.

Take this as an example:

https://vulnerable-site.tld/some-path/?param="<img/src/onerror=alert(origin)>

While this is a dangerous bug that can be leveraged in lots of ways but giving it to the victim will not be the solution for the attacker since the browser will not execute it if the X-XSS-Protection is enabled.

Ways to configure it

  1. X-XSS-Protection: 0: This will disable the filter entirely.
  2. X-XSS-Protection: 1: This will enable the filter but only sanitizes potentially malicious scripts.
  3. X-XSS-Protection: 1; mode=block: This will enable the filter and completely blocks the page.

Enable in Nginx (In Action)

  • Adding the following line to the Nginx default configuration file (etc/nginx/sites-enabled/your_config_file)

    add_header X-XSS-Protection "1; mode=block";

Content Security Policy (CSP)

Whitelisting » Blacklisting

Explaining

  • This is an improved version of the X-XSS-Protection we discussed earlier.
  • Powerful header to prevent XSS attacks (personally I’ve found a couple of XSS which couldn’t exploit them because of this header which was properly set :)
  • By whitelisting sources of approved content, you can prevent the browser from loading malicious assets/scripts.
  • Its implementation is tricky since you have to exactly know that you are going to whitelist otherwise you might break your site. (I once had experience breaking a client website by setting this header inappropriately and the external resources could not properly be loaded :)

Ways to configure it

  • Lots of ways just make sure you can have styles and scripts and images which are needed since most of the web apps rely on third parties.
  • You have to make sure you have whitelisted what origins are allowed to have scripts loaded from.
  • This is exactly the idea of whitelisting.

Enable in Nginx (In Action)

  • Adding the following line to the Nginx default configuration file (etc/nginx/sites-enabled/your_config_file)
  • add_header Content-Security-Policy "default-src 'self'; font-src *;img-src * data:; script-src *; style-src *";
  • Note: it is better to specify which script, style, etc are allowed instead of wildcarding.

Sample Nginx configuration

Here is a sample Nginx configuration that you can set.

Nginx config for security headers

securityheaders.com results

securityheaders.com is a great website that easily assesses the security of your HTTP response headers.