Using HTTPS
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 does not 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.)
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 Central Digital and Data Office (CDDO) 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 (for example 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.
Do not link to assets hosted by another service, like 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
The following videos explain how HTTPS works:
- Public Key Cryptography: Diffie-Hellman Key Exchange, from the Art of the Problem channel
- Secure web browsing, from the Computerphile channel
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.
Related guides
You may also find the following guides useful:
- Last update:
-
Guidance first published