At GOV.UK Verify we take users’ security very seriously. Online security is constantly changing, and we need to be up to date at all times. We regularly update the service’s frontend to ensure it’s running the most secure and recent software to protect our users and their data.
In this blog post, we’re going to demonstrate how we develop and change GOV.UK Verify to keep on top of security. We’ll be looking at Subresource Integrity (SRI) and Content Security Policy (CSP), which are two security features we use on our frontend.
Subresource Integrity (SRI)
Our frontend provides values for a user’s browser to verify files referenced in the page’s HTML. These are things like images, CSS and JavaScript, which have come from our server. This is called Subresource Integrity (SRI).
Our frontend uses the Ruby on Rails web framework so the change to enable SRI was very straightforward. Browsers that support SRI will use the integrity values. Older browsers will ignore them.
Browsers use the following supplied SHA-256 hash digest to run integrity checks on the file contents:
<link rel="stylesheet" media="screen" href="/assets/style.css" integrity="sha256-cMnkAaQWs5b1btFOxA476e4wcrhrsLaAFvQj3ugK4c4=">
With SRI enabled, the browser only loads files that pass integrity checks. This prevents the browser from loading any files that are unexpectedly manipulated, adding an additional layer of protection.
Content Security Policy
Content Security Policy (CSP) is a fairly new security standard introduced to prevent cross-site scripting (XSS), clickjacking and other attacks resulting from the execution of malicious content in a trusted web page. It helps website authors improve security by providing an allow list to restrict where an HTML page can load assets from. We can use CSP to ensure that images, JavaScript and stylesheets are only loaded from domains that we control.
We’ve posted about CSP before on the GDS technology blog. In his post, Alex Muller wrote about the limitations of CSP as it was back then. He noted that we’d be keeping an eye on how it was developing.
One example of CSP’s previous limitations was that it only allowed complete enabling or disabling of inline JavaScript. This would not work for us as, for performance reasons the GOV.UK template includes some inline JavaScript. At the time, Alex wrote that adopting CSP would become possible for us once it improved its specifications and browsers gradually implemented the Content Security Policy 2 (CSP2) specification.
Since Alex’s blog post, many more browsers have implemented CSP2. We now run CSP in the HTTP headers served from GOV.UK Verify and restrict browsers from running untrusted code. This greatly reduces the risk of certain types of attacks from happening in the user’s browser such as cross-site scripting attacks (XSS).
On the GOV.UK Verify frontend we moved all JavaScript into separate files, apart from the two inline pieces of JavaScript present in the govuk_template. We could then deploy CSP2 by specifically allowing those two inline scripts (this is done by providing integrity checks in a similar way to those used by Subresource Integrity).
Continuing to improve users’ security
We will continue to refine and strengthen the Content Security Policy, and plan to add Content Security Policy reporting, which we’ll blog about soon.
We are also working within GDS to add Subresource Integrity to the govuk_template.
You can follow David or William on Twitter, sign up now for email updates from this blog or subscribe to the feed.
You can also subscribe to the indentity assurance blog to keep up to date with our mission to improve GOV.UK Verify.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.
