The helmet module is a collection of Express middleware that provides some sane security defaults when included.
The first sane default is removing the X-Powered-By header.
In the previous recipe, we saw an older version of Express, with several known and public vulnerabilities.
Before we included helmet the header output contained:
X-Powered-By: Express
While there are other ways to identify an Express server, the first way we can harden our server is to prevent it being a low hanging fruit for automated attacks.
This is purely for obfuscation, but it makes our server statistically less vulnerable.
Next, helmet adds the X-DNS-Prefetch-Control with the value set to off. This instructs browsers not to prefetch DNS records for references within an HTML page (for instance, a link to a third-party domain may cause a browser to trigger a lookup request to the domain). While this (and other types of prefetching) seems like a good idea (for client-side performance), it does lead to privacy issues. For instance, a user on a corporate network may have appeared to access content that was only linked from a page. The helmet module disables this by default.
A popular alternative to helmet is lusca, it provides the same essential features as helmet and then some.
The next header, X-Frame-Options: SAMEORIGIN, prevents iframe-based https://en.wikipedia.org/wiki/Clickjacking where our site may be loaded in an <iframe> HTML element on a malicious site but positioned behind other content that instigates a user click. This click can then be used in a "bait and switch" where click actually applies to an element on our site within the iframe. Setting X-Frame-Options to SAMEORIGIN instructs the browser to disallow the endpoint to be loaded in an iframe unless the iframe is hosted on the same domain.
The X-Download-Options: noopen is an archaic throwback that attempts to protect what remains of the Internet Explorer 8 user base (it may, by now, at the time of reading, have been removed from helmet defaults). Internet Explorer 8, by default, opens downloaded files (such as HTML) with the authority of the site it was downloaded from. This header disables that behavior.
The MIME type of a document is important, it describes the structure of the content, for instance, text/css and application/javascript have very different qualities, expectations, and powers. Browsers can attempt to guess the MIME type of a document, and even in some cases (IE in particular), ignore the MIME type sent from the server. This opens up the possibility of attacks that bypass security mechanisms by veiling themselves in an alternative MIME type format, and then somehow switching back and being executed in their original format to run malicious code. A very sophisticated manifestation of this attack comes in the form of the Rosetta Flash attack created in 2004 to demonstrate the vulnerability (see https://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/). Setting the X-Content-Type-Options to nosniff instructs the browser to never guess and override the MIME type, rendering such attacks impossible.
The final X-XSS-Protection is supported in Internet Explorer and Chrome. The name is very much a misnomer since X-XSS-Protection provides very little protection from Cross Site Scripting. In fact, in Internet Explorer 8, when it was introduced, the X-XSS-Protection header created an XSS vulnerability. So this piece of helmet also performs User Agent detection and disables it for Internet Explorer 8.
We address Cross Site Scripting in detail in the Guarding Against Cross Site Scripting (XSS) recipe in this chapter.
Setting the X-XSS-Protection header to 1; mode=block instructs Internet Explorer to refuse to render when it detects a Reflected XSS attack (for example, a non-persistent attack, such as crafting a URL with a query parameter the executes JavaScript). In Chrome the X-XSS-Protection header is used to opt-out (by setting to 0) of Chromes XSS auditor, which will automatically attempt to filter out malicious URL pieces.
In either case, the XSS-Protection header shouldn't be relied on as complete protection from XSS attacks, since it deals only with Reflected XSS, which is only one type.
Additionally, the ability for a browser to detect a reflected XSS attack place is nontrivial (and can be worked around, see the Guarding Against Cross Site Scripting (XSS) recipe).
One other header that helmet sets by default is the Strict-Transport-Security, which is only enabled for HTTPS requests. Since we don't have HTTPS implemented,
we don't see this header in output. Once a browser visits a site over HTTPS using the Strict-Transport-Security that browser becomes locked-in to using HTTPS, every subsequent visit must use HTTPS.
The helmet library can also enable a few other headers. In some cases, we may wish to disable client caching. The helmet.noCache middleware will set a variety of headers so that caching is eradicated from old and new browsers alike, as well as instructing Content Delivery Networks (CDNs) to drop the cache. The helmet.referrerPolicy restricts the Referrer header, which privacy conscious users may appreciate. The helmet.hkpk middleware sets the Public-Key-Pins header, which we have to supply with a public key that appears in a sites SSL certificate chain. This causes the browser to store the key, and compare it on subsequent requests thus securing against the the possibility of a rogue Certificate Authority (CA) (or other SSL-based Person in the Middle attack) Finally, there's the helmet.contentSecurityPolicy middleware that we'll explore in more detail in the Guarding Against Cross Site Scripting (XSS) recipe in this chapter.