[Nginx Security] Nginx Header Security

Nginx Header Security

Here’s how to add various HTTP response header to your Nginx site for better website security protection.

X-Frame-Options avoid click-jacking attacks

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Sites can use this to avoid click-jacking - https://developer.mozilla.org/en-US/docs/Web/Security/Types_of_attacks#click-jacking attacks, by ensuring that their content is not embedded into other sites.

add_header X-Frame-Options SAMEORIGIN;

If you specify DENY, not only will attempts to load the page in a frame fail when loaded from other sites, attempts to do so will fail when loaded from the same site. On the other hand, if you specify SAMEORIGIN, you can still use the page in a frame as long as the site including it in a frame is the same as the one serving the page.

• DENY

  The page cannot be displayed in a frame, regardless of the site attempting to do so.

• SAMEORIGIN

  The page can only be displayed in a frame on the same origin as the page itself.

• (Deprecated) ALLOW-FROM uri

  This is an obsolete directive that no longer works in modern browsers. Don’t use it.

X-Content-Type-Options blocks a request if the request destination is of type

The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This is a way to opt out of MIME type sniffing, or, in other words, to say that the MIME types are deliberately configured.

# Blocks a request if the request destination is of type.
add_header X-Content-Type-Options nosniff;

X-XSS-Protection block pages from loading when they detect reflected XSS attacks

The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks.

• 0

  Disables XSS filtering.

• 1

  Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).

• 1; mode=block

  Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.

• 1; report= (Chromium only)

  Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.

# Block pages from loading when they detect reflected XSS attacks.
add_header "X-XSS-Protection" "1; mode=block";

Strict-Transport-Security tell browsers should only be accessed using HTTPS

The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP.

# Tell browsers should only be accessed using HTTPS within 31536000 seconds after the first HTTPS access.
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";

• max-age=

  The time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS.

• includeSubDomains (Optional)

  If this optional parameter is specified, this rule applies to all of the site’s subdomains as well.

• preload (Optional)

  See Preloading Strict Transport Security - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security#preloading_strict_transport_security for details. Not part of the specification.

Google maintains an HSTS preload service. After successfully submitting your domain name according to the following instructions, the browser will never connect to your domain name in an insecure way. Although the service is provided by Google, all browsers have the intention of using this list (or are already using it). However, this is not part of the HSTS standard and should not be regarded as an official content.

• HSTS preload list of Chrome & Chromium: HTTP Strict Transport Security - The Chromium Projects - https://www.chromium.org/hsts

• HSTS preload list for Firefox: nsSTSPreloadList.inc

Enter chrome://net-internals/#hsts to enter the HSTS management interface, and you can add/delete/query HSTS records.

Add the website to the preload list: HSTS Preload List Submission - https://hstspreload.org/

Content-Security-Policy control what resources the user agent is allowed to load for that page

Configuring Content Security Policy involves adding the Content-Security-Policy HTTP header to a web page and giving it values to control what resources the user agent is allowed to load for that page. For example, a page that uploads and displays images could allow images from anywhere, but restrict a form action to a specific endpoint. A properly designed Content Security Policy helps protect a page against a cross site scripting attack. This article explains how to construct such headers properly, and provides examples.

# A web site administrator wants all content to come from the site's own origin (this excludes subdomains.).
add_header Content-Security-Policy: default-src 'self';

add_header Content-Security-Policy: "default-src 'self' trusted.com *.trusted.com"

Set-Cookie

An easy way to set cookie flag as HTTPOnly and Secure in Set-Cookie HTTP response header. Take a backup of the necessary configuration file and add the following in nginx.conf under http block.

add_header Set-Cookie "Path=/; HttpOnly; Secure";

Another alternative option is to add the below syntax in ssl.conf or default.conf

proxy_cookie_path / "/; HTTPOnly; Secure";

add_header directive

Syntax:	add_header name value [always];
Default:	—
Context:	http, server, location, if in location

Adds the specified field to a response header provided that the response code equals 200, 201 (1.3.10), 204, 206, 301, 302, 303, 304, 307 (1.1.16, 1.0.13), or 308 (1.13.0). Parameter value can contain variables.

There could be several add_header directives. These directives are inherited from the previous configuration level if and only if there are no add_header directives defined on the current level.

---

If the always parameter is specified (1.7.5), the header field will be added regardless of the response code.

---

add_header | Module ngx_http_headers_module - https://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header

References

[1] Module ngx_http_headers_module - https://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header

[2] How to configure Security Headers in Nginx and Apache - https://webdock.io/en/docs/how-guides/security-guides/how-to-configure-security-headers-in-nginx-and-apache

[3] [NGINX Security Headers, the right way - GetPageSpeed - https://www.getpagespeed.com/server-setup/nginx-security-headers-the-right-way][https://www.getpagespeed.com/server-setup/nginx-security-headers-the-right-way]

[4] X-Content-Type-Options - HTTP | MDN - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

[5] X-XSS-Protection - HTTP | MDN - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

[6] Strict-Transport-Security - HTTP | MDN - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

[7] HSTS Preload List Submission - https://hstspreload.org/

[8] HTTP Strict Transport Security - The Chromium Projects - https://www.chromium.org/hsts

[9] Content Security Policy (CSP) - HTTP | MDN - https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

[10] How to Implement HTTPOnly and Secure Cookie in Nginx? - https://geekflare.com/httponly-secure-cookie-nginx/