In today’s world, one can never go too far in securing their on-line assets, and in most cases, our web sites are our most sensitive assets. This assertion is increasingly true in the small business and non-profit sectors, where increasing geopolitical ferment is colliding with an AI fueled explosion of hacking capabilities to make everybody both a potential attacker and target! In this article I’m going to discuss using HTTP Headers to improve the security of one’s web site.

HTTP Headers are pieces of meta-data describing conditions appurtenant to the request that a browser is making or the response that a server is providing. When a person clicks on a link in a web browser, the browser typically sends a request called a GET request over the HTTP protocol that serves as the basis for most communication on the internet. In addition to specifying the link target (e.g. the desired resource, commonly a web page), the request can include additional pieces of information qualifying the request. For instance, Mozilla provides this canonical GET request in their on-line documentation:

GET /home.html HTTP/1.1

Host: developer.mozilla.org

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate, br

Referer: https://developer.mozilla.org/testpage.html

Connection: keep-alive

Upgrade-Insecure-Requests: 1

If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT

If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"

Cache-Control: max-age=0

The lines following GET /home.html HTTP/1.1 are Request Headers, where the words at the beginning of each line preceeding the colon are individual Request Headers and the text following the colon are the values assigned to the Header in the current request. In a case like this the purpose for most of the headers is self explanatory, but if you are curious, go ahead and look them up. The universe of legitimate headers is described in several Internet standards documents.

When the server receives the GET request, its job is to return the requested resource, for our purposes often a web page. In its response the server can include Response Headers, which generally provide context for the response and tell the browser how it can use the resource. Again Mozilla provides a canonical HTTP response:

200 OK

Access-Control-Allow-Origin: *

Connection: Keep-Alive

Content-Encoding: gzip

Content-Type: text/html; charset=utf-8

Date: Mon, 18 Jul 2016 16:06:00 GMT

Etag: "c561c68d0ba92bbeb8b0f612a9199f722e3a621a"

Keep-Alive: timeout=5, max=997

Last-Modified: Mon, 18 Jul 2016 02:36:04 GMT

Server: Apache

Set-Cookie: my-key=my value; expires=Mon, 17-Jul-2017 16:06:00 GMT; Max-Age=31449600; Path=/; secure

Transfer-Encoding: chunked

Vary: Cookie, Accept-Encoding

X-Backend-Server: developer2.webapp.scl3.mozilla.com

X-Cache-Info: not cacheable; meta data too large

X-kuma-revision: 1085259

x-frame-options: DENY

The structure of the Header declarations is the same for Response Headers as for Request Headers, as they both are implementations of the HTTP protocol. Mozilla groups Response Headers into over twenty (20) categories, which you can see listed in the right column of the documentation page I linked above.  Within these categories, there are dozens of possible Response Headers and the above example only shows a few of them. In fact, it does not show many of the Response Headers in the Security Category, which is what we are interested in today.  

Response Headers in the Security Category, which we will hereinafter refer to as simply Security Headers, allow the web site owner or application developer to specify rules about how the requested resource may be used; these rules are used to enforce various security protections. Mozilla Developer Network provides a great way to understand your site’s security posture and learn about Security Headers with their HTTP Observatory. This online tool takes a URL, scans it, analyzes the security headers and assesses the security posture of the site based on the security header settings. Here let me point out that setting Security Headers is a necessary but not sufficient condition for protecting web sites and applications.

Now, some readers will point out that Mozilla’s HTTP Observator is not the only Security Header scoring site; I have used SecurityHeaders.com and the Serpworx Security Headers page. SecurityHeaders.com evaluates fewer headers than HTTP Observatory, while Serpworx includes a few more. HTTP Observatory is more geared to providing advice on how to fix issues yourself, which the others, being provided by vendors, are more geared to suggesting you use their products. Let me take a web site that I manage (www.ecwise.com), which currently has the worst SecurityHeaders.com score possible, an F, and show you the SecurityHeaders.com output:

Missing Headers

The additional Security Headers that Serpworks and HTTP Observatory looks for are

So now we know what Security Headers are and how to determine if our web sites and applications are using them effectively. Let’s see how we can use this knowledge to set Security Headers on our web sites. I’m going to start with WordPress sites, because that’s where I have had the most experience lately. While one would think that this would work consistently across WordPress sites, there’s enough variation between hosting providers that its not a cookie cutter process.

It is important to realize that WordPress is not itself a web server. In reality, it is a content management system that stores content across its file system and a database, and provides PHP code that renders that content as web pages when they are requested. It relies on the availability of a PHP interpreter and the appropriate web server interface to PHP in order to serve web sites. Most of the time all this ‘plumbing’ is preconfigured by your hosting provider who is generally providing you shared use of a Linux server running the Apache web server. There are also WordPress installations running on Microsoft IIS, but this is relatively unusual.

One Apache instance running on a server (or virtual machine) can run multiple web sites. Each site should have a configuration file named .htaccess, where one can set site level parameters like HTTP Response Headers. As an example, my web host (Dreamhost) creates separate subdirectories for each of my websites, as you can see in the screen shot from their file manager.

There is an .htaccess file in each of the directories shown in the red box. These are my SecurityHeaders for howmanychildren.org:

<IfModule mod_headers.c>

  Header always set X-Content-Type-Options “nosniff”

  <FilesMatch “\.(php|html)$”>

    Header set X-Frame-Options “SAMEORIGIN”

    Header set Strict-Transport-Security “max-age=2592000” env=HTTPS

    Header set Content-Security-Policy “default-src ‘self’; script-src ‘self'”

    Header set Referrer-Policy “same-origin”

    Header set Permissions-Policy “geolocation=*”

  </FilesMatch>

</IfModule>

While I could go further, that is sufficient to get a decent security score. Now, you can edit the .htaccess file directly to add Header set statements (and I appreciate that Dreamhost has a very easy to use editor built into their file browser. So far, so good, but one challenge is that not all web sites are organized this “nicely”, nor is .htaccess globally enabled.

I put the PivotPayables.com and ECWise.com web sites on Amazon Web Services “Lightsail” service (comparing Lightsail and Dreamhost would take another article!). On Lightsail, one must enable .htaccess with the AllowOverride All (the default is AllowOverride None) setting in the /opt/bitnami/apache2/conf/vhosts/wordpress-https-vhost.conf file. Then, finding your way through the file system on Lightsail to where the applicable .htaccess file resides can be challenge; it is generally in /opt/bitnami/wordpress.

If you are familiar with WordPress you are probably aware of plug-ins. Plug-ins do everything in WordPress beyond fairly basic content management, so they are fairly rampant and come with their own set of security challenges. That said, I found the free HTTP Headers plug-in to be quite useful. It supports setting the HTTP Headers listed on the web site, and more, grouping them into Security, Access Control, Authentication, Compression, Caching and Miscellaneous categories. Here’s a screenshot of some of our settings on the Security page:

Regardless of how you want to edit your .htaccess file, you will want to make incremental changes and backups every step of the way. In particular, Content-Security-Policy directives are very tricky when using WordPress themes, because themes often invoke remote scripts and sometimes even remote css style directives. In my opinion, this is a really bad idea, but I’ve seen it done. Once your web site invokes remote script, which can be a result of using a visitor tracking service like the omni-present Google Analytics, then you have to allow remote content to execute on your site.

This is obviously a topic that has a lot of layers. For instance, what do each of these headers really do? I think I’ve gone far enough for an introductory article, so I’ll leave it at that and rely on feedback to convince me to write a follow-up 😊.