{"id":916,"date":"2020-12-04T16:33:00","date_gmt":"2020-12-05T00:33:00","guid":{"rendered":"https:\/\/www.cloudinsidr.com\/content\/?p=916"},"modified":"2022-11-30T05:30:02","modified_gmt":"2022-11-30T13:30:02","slug":"fixing-your-web-servers-security-headers-from-hall-of-shame-to-hall-of-fame","status":"publish","type":"post","link":"https:\/\/www.cloudinsidr.com\/content\/fixing-your-web-servers-security-headers-from-hall-of-shame-to-hall-of-fame\/","title":{"rendered":"Fixing your Web Server’s Security Headers: From Hall of Shame to Hall of Fame"},"content":{"rendered":"

[Updated 2022-11-30] This post explains how to set up robust security headers in NGINX to protect your web application from malicious payloads and other forms of attacks. Choose your HTTP(S) headers wisely.<\/p>\n

<\/p>\n

In order to effectively prevent (or sufficiently hinder) some of the nastiest hacks, your web servers can send a couple of sophisticated HTTP security headers.\u00a0A few options in\u00a0a configuration file can prevent a serious cyber security incident.<\/p>\n

Activate HTTP Strict-Transport-Security (HSTS)<\/h2>\n

HTTP Strict-Transport-Security (HSTS) enforces secure connections over HTTPS (after the initial handshake). To set this header, enter this line in the server block of the NGINX configuration file for your site:<\/p>\n

add_header Strict-Transport-Security \"max-age=31536000; includeSubDomains; preload\";<\/pre>\n
Set X-Frame-Options to prevent clickjacking attacks<\/h2>\n
The\u00a0X-Frame-Options header:<\/p>\n
add_header X-Frame-Options \"sameorigin\";<\/pre>\n
was devised to prevent clickjacking<\/strong> (UI redress<\/strong>) attacks, where a hacker uses multiple transparent or opaque layers to trick a user into clicking on a page element that triggers an undesired\u00a0event.<\/p>\n
Set X-Content-Type-Options to disallow\u00a0circumventing declared MIME types<\/h2>\n
The header (with the only supported value nosniff<\/strong>):<\/p>\n
add_header X-Content-Type-Options nosniff;<\/pre>\n
reduces exposure to drive-by attacks by preventing browsers (Internet Explorer and Google Chrome) from MIME-sniffing a response away from the declared content-type, which would allow to\u00a0execute cleverly (and inappropriately) named\u00a0files after an upload to your server initiated by a malicious user.<\/p>\n
Activate X-XSS-Protection<\/h2>\n
The header X-XSS-Protection<\/strong>:<\/p>\n
add_header X-XSS-Protection \"1; mode=block\";<\/pre>\n
can prevent cross-site-scripting<\/strong> (XSS) attacks.<\/p>\n
Create a Content Security Policy<\/h2>\n
In order to complete your setup, create a\u00a0Content Security Policy<\/a>\u00a0for your server. Without a content security policy, a web browser has no way of knowing if code injection from an external domain is legitimate and intended by the website owner or not. A too restrictive or plain outdated content security policy will have another major drawback: it may prevent the execution of code supplied from external domains. In other words: your ads, social media widgets or other code may stop running.<\/p>\n
For details on how to create a content security policy that’s both protective and functional, read\u00a0Secure Your Web Server against Attacks via XSRF\/CSRF\/XFS: How to Design a Content Security Policy<\/a>.<\/p>\n
Add a Referrer-Policy header to limit information sent out in the Referrer string<\/h2>\n
Your web server might inadvertently disclose sensitive information by sending the full origin URL in the referrer to an external destination. This behavior is highly problematic as an attacker could divulge not merely host names, but directory names and variables, possibly including even user names or other identifiers, from the referrer. In order to limit your server’s exposure, it is advisable to set a referrer policy header (browser support varies<\/a>).<\/p>\n
A Referrer-Policy header will sanitize the referrer string according to your chosen setting. You could even suppress the referrer entirely. A word of caution: if your website relies on advertising revenue or affiliate links, removing the referrer might render the attribution of sales all but impossible.\u00a0<\/strong><\/span><\/p>\n
The Referrer-Policy header supports the following parameters:<\/p>\n