Security Hardening - Nginx Response Headers

ByKarthik Kumar D Kon20th Jun 2021, 2022-12-01T08:00:00+05:30
Read Article
Security Hardening - Nginx Response Headers

Now-a-days, web based attacks are one of the most common types of cybercrime, and in most cases, the attacked protocol is the HTTP, while the component that receives the attacks is the web server. Hardening Nginx HTTP headers becomes necessary for reducing any attacks to the web server.

And how to harden Nginx response HTTP headers? - HTTP headers are pieces of information that can be found when you interact with an HTTP server. These headers are among the most important parts of the HTTP request (made by HTTP clients, such as your web browser) and HTTP responses (made by HTTP servers such as Nginx).

Within these HTTP headers, one can identify how the request was processed by the web server, the type of HTTP status, and other data. There are two kinds of headers: those that are vulnerable, and those that are secure.

HTTP Header Vulnerable vs Secured..?

To note, the less information you expose on the Internet, the less data a penetration tester or real malicious attacker will find.

Let's look at two examples, a vulnerable HTTP header vs a hardened HTTP header.

1. Vulnerable HTTP Header example
$ curl -I http://drupal.local
HTTP/1.1 200 OK
Server: nginx/1.18.0
Content-Type: text/html; charset=UTF-8

You can see a few headers vulnerable like, nginx server version is exposed as 1.18.0.

2. Hardened HTTP header example

Lets see the example of hardened headers below, where the server version is hidden & other headers like content-security-policy, x-frame-options etc are set.

$ curl -I
HTTP/2 200
server: nginx
content-type: text/html; charset=utf-8
x-drupal-cache: MISS
x-ua-compatible: IE=edge
fastly-restarts: 1
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
content-security-policy: frame-ancestors 'self'
permissions-policy: interest-cohort=()
strict-transport-security: max-age=15552000; includeSubDomains; preload
content-length: 100930

Tips to Secure & Harden HTTP Response Headers!

1. Hide PHP version

The PHP version can be disabled by altering PHP configuration i.e by modifying the expose_php variable from the php.ini file.

expose_php = Off

2. Hide Nginx server version

The server_tokens variable allows you to hide the nginx version in the response headers.

ServerTokens off

3. Enable Content Security Policy (CSP)

Content Security Policy defines which resources from your websites can be loaded by any remote web browser, including Javascript and CSS files.

Content-Security-Policy: default-src 'self' \*.drupal.local
Content-Security-Policy: script-src 'self'

add_header Content-Security-Policy-Report-Only: "default-src 'self'; script-src *.drupal.local";

4. Enable HTTP Strict Transport Security

You can reduce the chances of becoming a victim to a man-in-the-middle attack by enabling HTTP Strict Transport Security.

server {
    listen 443 ssl
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

5. Enable X-Content-Type-Options

You can ensure the browser will render the data as original, and not as any other by adding the X-Content-Type-Options.

add_header X-Content-Type-Options "nosniff" always;

6. Enable X-Frame-Options

In case, if Iframes are used then clickjacking attacks can be done, with this sensitive data from users can be stolen. So to reduce this risk, have the X-Frame-Options in headers.

add_header X-Frame-Options "SAMEORIGIN" always;

7. Enable Referrer Policy

Referrer Policy allows you to control what information can be included in the Referrer header while navigating from pages on your site. By doing this makes it impossible to track these requests while navigating away from your site.

add_header Referrer-Policy "origin-when-cross-origin" always;

8. Control Resources and Limits

To prevent potential DoS attacks on nginx, you can set buffer size limitations for all clients.

client_body_buffer_size 1k
client_header_buffer_size 1k
client_max_body_size 1k
large_client_header_buffers 2 1k

9. Configure SSL and Cipher Suites

Default configuration of nginx will use insecure old versions of the TLS protocol. This may lead to attacks such as the BEAST attack. So you can configure nginx to have TLSv1.2 or v1.3.

Additionally, you should specify cipher suites to make sure that no vulnerable suites are supported.

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;

So, by having such response headers configured on the web server, we can make sure the website is not prone to vulnerabilities and be safe from attacks.

We Need Your Consent
By clicking “Accept Cookies”, you agree to the storing of cookies on your device to enhance your site navigation experience.
I Accept Cookies