Implementing HTTP security headers are an important way to keep your site and your visitors safe from attacks and hackers. In a previous post, we dove into how the X-Frame-Options header and frame-ancestors directive can help combat clickjacking. In today’s post, we want to go more in-depth with the X-XSS-Protection header, as well as the newer CSP Reflected-XSS directive, and how they can help prevent cross-site scripting (XSS) attacks.

What is X-XSS Protection?

The x-xss-protection header is designed to enable the cross-site scripting (XSS) filter built into modern web browsers. This is usually enabled by default, but using it will enforce it. It is supported by Internet Explorer 8+, Chrome, and Safari. The recommended configuration is to set this header to the following value, which will enable the XSS protection and instruct the browser to block the response in the event that a malicious script has been inserted from user input, instead of sanitizing.

x-xss-protection: 1; mode=block

How widely is the x-xss-protection header being used? Scott Helme did an interesting case study back in February 2016. He analyzed the security headers of the top 1 million sites, according to Alexa, and this is what he found. It is shown as XXSSP below in the chart. Only 5.1% of the top sites are utilizing the header.

Cross-site Scripting (XSS)

Cross-site scripting, also known as XSS, is basically a way to inject code that will perform actions in the user’s browser on behalf of a website. Sometimes this is seen by the user and sometimes it can go totally unnoticed in the background. There are many different types of XSS vulnerabilities, below are two of the most common.

Reflective XSS: These are usually the most common types. Typically these are within HTTP query parameters and are used by server-side scripts to parse and display a page of results for the user.
Persistent XSS: These are when the data from the attacker is actually saved on the server and then displayed to the user, mimicking a normal page.

Other XSS vulnerabilities include DOM-based, stored server, reflected server, stored client, reflected client, and subset of client. Below is an example of how an XSS attack works.

Here is another good example of executing JavaScript from within a form.

According to CVE details, a security vulnerability database, since 2009 there have been over 9,903 major XSS attacks recorded. After DDoS and code execution, XSS attacks are very common.

X-XSS-Protection Directives

A 0 value disables the XSS Filter, as seen below.

x-xss-protection:0;

A 1 value enables the XSS Filter. If a cross-site scripting attack is detected, in order to stop the attack, the browser will sanitize the page.

x-xss-protection:1;

A 1; mode=block value enables the XSS Filter. Rather than sanitize the page, when an XSS attack is detected, the browser will prevent rendering of the page.

x-xss-protection:1; mode=block

The x-xss-protection header is easy to implement and only requires a slight web server configuration change. You might also want to check to make sure you don’t already have the header enabled. Here are a couple easy ways to quickly check.

1. Open up the network tab in Chrome DevTools and if your site is using a security header it will show up on the Headers tab. You can see below that even we are using this security header on the KeyCDN blog.
   
2. Another quick way to check your security headers is to quickly scan your site with a free tool, securityheaders.io, created by Scott Helme. This gives you a grade based on all of your security headers and you can see what you might be missing.

Enable in Nginx

add_header x-xss-protection "1; mode=block" always;

Enable in Apache

header always set x-xss-protection "1; mode=block"

Enable on IIS

To enable on IIS simply add it to your site’s Web.config file.

  ...

  <httpProtocol>
    <customHeaders>
      <add name="X-Xss-Protection" value="1; mode=block" />
    customHeaders>
  httpProtocol>

  ...

Reflected-XSS Directive

An important thing to keep in mind is that the X-XSS-Protection header is pretty much being replaced with the new Content Security Policy (CSP) Reflected-XSS directive. The reflected-xss directive instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks. Valid values are allow, block, and filter. This directive is not supported in the element.

However, it is not supported in all browsers yet, and so it is still recommended to use the x-xss-protection header. However, you could use both the x-xss-protection and reflected-xss together.

Summary

Hopefully, now you understand a little more about what the x-xss-protection HTTP response header does and how it can help prevent cross-site scripting (XSS) attacks. As seen above, this is very easy to implement. We use security headers on our websites and we encourage you to do the same. Together we can make the web a more secure place and help boost the security header usage numbers.

Related Articles