WordPress powers over 36.1 percent of the entire internet with a 63.2% market share, so it’s no surprise websites using WordPress are a common target for hackers. While the WordPress Security Team does a fantastic job staying on top of vulnerabilities, numerous other precautions can be taken. One example is Secure HTTP response headers.

Introduction

HTTP Response headers are name-value pairs of strings sent back from a server with the content you requested. When you access a website, the browser requests a web server. The server then responds with the request along with “response headers”. They are typically used to transfer technical information like how a browser should cache content, what type of content it is, the software running on the server, and much, much more. Increasingly, HTTP Response headers have been used to transmit security policies to the browser.

Additional Headers

The first step in hardening your HTTP response headers is looking at the additional headers you can utilize to make your site more secure. Outlined below, these headers give the browser more information about how you want it to behave with regard to your site. They can be used to deliver security policies, set configuration options, and disable features of the browser you don’t want to be enabled for your site. Once you have set up each header, check it using SecurityHeaders.io.

Why HTTP Response Headers

Adding secure HTTP response headers provides an additional layer of security by helping to mitigate attacks and security vulnerabilities. These headers can be added at the server level in Apache, NGINX, and others. The issue is that many times access to the files will be restricted by the hosting company or beyond a person’s technical comfort zone.

On this site, I’m adding the secure headers via the WordPress functions.php file as follows:

I can also add those secure header via the .htaccess file as follows:

At a very basic level, here is what each of these responses is doing:

  • Strict-Transport-Security enforces the use of HTTPS. This is important because it protects against passive eavesdropper and man-in-the-middle (MITM) attacks.
  • X-Frame-Options prevents clickjacking attacks and helps ensure your content is not embedded into other sites via <frame><iframe> or <object>.
  • Content-Security-Policy tells the browser where resources are allowed to be loaded and if it’s allowed to parse/run inline styles or Javascript. This is important because it prevents content injection attacks, such as Cross-Site Scripting (XSS).
  • X-Content-Security-Policy is required for CSP support in IE 10 and IE 11. For other modern browsers, the Content-Security-Policy header should be used.
  • X-XSS-Protection sets the configuration for the cross-site scripting filters built into most browsers. This is important because it tells the browser to block the response if a malicious script has been inserted from user input.
  • X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. This is important because the browser will only load external resources if their content type matches what is expected, and not malicious hidden code.
  • Referrer-Policy allows control/restriction of the amount of information present in the referral header for links away from your page—the URL path or even if the header is sent at all.

If you want to dig in a bit deeper and learn more, SecurityHeaders.io is a great place to start.

The article was published on January 17, 2018 @ 10:32 AM

Leave a Comment