Beta This is new guidance. Complete our quick 5-question survey to help us improve it.

Many services collect personal information from users or present information to them which they then use to make important decisions.

It’s important that you build a service that doesn’t allow this information to be intercepted or modified by malicious third parties as it travels over the internet.

This means you must make sure your service (including APIs) is only accessible through secure connections. For web-based services this means HTTPS only, with an HTTP Strict Transport Security (HSTS) configuration as explained in this guide.

(HTTPS describes the use of TLS, a lower level protocol previously known as SSL, to secure HTTP requests.)

Meeting the Digital Service Standard

To pass point 7 (understand security and privacy issues) in your service assessments, you’ll need to explain how you’ve made your service secure.

Configuring HSTS

HSTS is an extension to the HTTPS protocol that tells web browsers that subsequent connections to a site must use HTTPS, and not an insecure protocol.

This helps defend users from attacks on subsequent visits to a site. Browser vendors can also preload this configuration in their browsers to defend users on their first connection to the site.

You should use this HSTS header which the Government Digital Service (GDS) recommends: Strict-Transport-Security: max-age=31536000, includeSubDomains; preload;

Read National Cyber Security Centre (NCSC) guidance on using TLS for external-facing services.

Serving your assets efficiently

The way your users’ browsers access your service’s assets (eg stylesheets, JavaScript, images) may change their opinion of the service, and this can affect its success.

In particular, how and where they’re hosted can have a dramatic impact on perceived and actual page-load times.

Don’t link to assets hosted by another service, eg GOV.UK, as their location may change without notice and break your service.

Historically, limitations in HTTP/1.1 have resulted in practices designed to work around these limitations. In response to many of these limitations, HTTP/2 has been developed which does not require these workarounds, and which will provide better performance once deployed.

HTTP/1.1 and HTTP/2 can be concurrently supported by web server software, and if HTTP/2 is not supported by the browser, HTTP/1.1 will be used.

In early 2016, support for HTTP/2 in web browsers in use was measured at around 56%, and rising rapidly.

Depending on the browsers in use by your users, you may decide to optimise for HTTP/1.1 users. In this case, common practice is to serve assets from a separate hostname (this avoids sending bulky cookies in requests for assets).

For example, if your service is at www.servicename.service.gov.uk, you should serve your assets from assets.servicename.service.gov.uk.

Further reading

For more detailed information about optimising web application performance and particularly for optimising for HTTP/1.1 or HTTP/2, see Chapter 13 of High Performance Browser Networking.

You may also find the following guides useful: