Security overview for websites
These steps are primarily for running independent websites that are not on the service.gov.uk domain.
Access Control
Must Do
Use named accounts to log in for all systems (from registrars to content management systems).
Use Single Sign-On (SSO) wherever possible to link accounts to Microsoft Entra ID, using OAuth or OIDC. If the service does not support SSO, make sure you use a gov.uk email and enable multi-factor authentication (MFA), ideally using a phishing-resistant mechanism like WebAuthn (hardware keys).
If applicable, use more secure forms of MFA for higher risk accounts. For example, hardware tokens such as Yubikeys for privileged accounts, app-based authentication for standard accounts, and SMS MFA for low risk accounts.
Where SSO is not available, or as an additional measure where possible, consider using context-aware access controls (see Google for example).
Consider what monitoring and alerting should be implemented for privileged account login/use.
Have a process to review who has access regularly.
If available, enable different roles for different people’s needs.
See how to manage access to your third-party service accounts for more details.
Why?
Using named accounts makes incident response and non-repudiability (making it harder for someone to deny they were responsible) easier. If an incident occurs, named accounts make it easier to work out the cause or vector and to then restrict access.
Using SSO makes Joiners, Movers and Leavers (JML) processes simpler. As soon as someone leaves and their Microsoft account is removed, their access to services will be removed.
Using MFA prevents many common forms of attack that would otherwise give attackers access to accounts.
Context-aware access further limits unauthorised access where credentials have been compromised.
See the NCSC’s guidance on identity and access management.
Domain Name System
Must Do
Domain Name System (DNS) is where your registrar points to, using Name Server (NS) records, and contains the records for web servers, email and other applications.
DNS is managed by the Cloud Platforms team, and you should ensure that the DNS is correctly configured to work with your service and follows best practice.
If you don’t need email to or from the domain name, request to disallow sending emails using the domain name. This involves adding four records (an MX and three TXT records). See NCSCs protecting parked domains guidance.
If you do need email to or from the domain name, ensure that best practices are being followed such as setting up the appropriate:
- Sender Policy Framework (SPF) TXT record
- Domain Keys Identified Mail (DKIM) TXT record(s)
- Domain-based Message Authentication, Reporting, and Conformance (DMARC) TXT record, and use the NCSC’s Mail Check
Why?
Inadequate DNS controls could lead to an adversary pointing your domain to a malicious site or version of your site. One such attack is called DNS hijacking.
Without implementing appropriate email DNS records, you could be at risk of enabling email spam from your domain, which would impact your search results and ranking.
Patching
Must Do
If your service uses a non-managed infrastructure or uses a Content Management System (CMS) then you or your supplier must have processes in place for keeping the system and software up-to-date.
Consider setting up a patching schedule with the development team or supplier to manage the patching process. You may want to:
- introduce this as a formal item in any governance meetings
- consider including any periods where you may want to pause or defer patches if you are concerned about availability during key events
If you are using Infrastructure-as-a-Service (IaaS) or Platform-as-a-Service (PaaS), you may want to set up a regular pipeline that gets the latest updates, tests your website or application with those, and then pushes the tested updates to your live environment.
See NCSC’s guidance on patching for more information about patching.
Why?
If you neglect to patch and keep the systems up-to-date, adversaries may use known vulnerabilities to impact your service.
Development, Test or Staging Environments
Must Do
Do not overlook the security of these environments, as a compromise or incident may cause the same disruption to your development team or supplier as in the live environment.
Consider setting up an IP allowlist or additional access controls to only allow authorised people to access.
If you’re using different domains, follow the same principles listed throughout this guidance, including setting appropriate and public WHOIS information.
Do not have actual user data (logins or personal information) in these environments.
Consider removing notification ability or restricting it to designated recipients to stop accidental notifications.
Security Headers
Must Do
Configure appropriate security headers to help your users’ browsers understand what your service should be doing:
| HTTP Header | Notes |
|---|---|
| Strict-Transport-Security | Also known as HTTP Strict Transport Security (HSTS), tells browsers to enforce HTTPS |
| Content-Security-Policy | see below for details on CSP |
| X-Content-Type-Options | When set to “nosniff” it tells browsers not to assume a content type |
| X-Frame-Options | Can defend against clickjacking |
| Referrer-Policy | Tells browsers how much information to give to third party services when a user clicks their links on your site |
| Permissions-Policy | Allows control of the browser features, such as denying access to the webcam if your website or service does not need to access it |
| Cross-Origin-Embedder-Policy | Sets the permission for how assets are loaded |
| Cross-Origin-Opener-Policy | ^ |
| Cross-Origin-Resource-Policy | ^ |
| Feature-Policy |
Deprecated (see OWASP guidance on Feature-Policy). Previously used to specify features the browser could access, primarily replaced with Permissions-Policy
|
| Expect-CT | Deprecated (see OWASP guidance on Expect-CT). Previously used by browsers to check the certificate transparency logs, which helps determine the legitimacy of a HTTPS connection. It is no longer needed as a response header |
| X-XSS-Protection |
Deprecated (see OWASP guidance on X-XSS-Protection). Previously used to mitigate XSS (cross-site scripting), this has been deprecated and should be set to 0 to disable the functionality in older browsers |
Remove/disable the “Server” header. This is slightly contradictory to the NCSC’s Secure by Design principle of “security through obscurity should be avoided” but it does make it more challenging to target your service.
You can find an example of implementing the headers using Talisman in the Funding Service config.
Use the Security Headers tool to check your security headers. Tick the “Hide results” checkbox before clicking “Scan”.
Why?
Security headers help users’ browsers determine the intended functionality of your website or service and make it more difficult for an adversary to cause an incident.
Content Delivery Network
Should Do
Along with Access Control for the provider, make it harder to cause a denial-of-service attack against your service by using a Content Delivery Network (CDN), such as AWS Cloudfront or Cloudflare.
Configure appropriate caching so that the CDN can serve most, if not all, traffic.
Implement origin access controls so that the origin cannot be impacted directly. The recommended approach in AWS is to add a ‘secret’ header from the CDN to the origin and have the origin check that header in an AWS WAF rule.
If you are using CloudFront:
- Consider limiting the edge locations if you only expect traffic originating from the UK.
- Set up AWS Shield Advanced (it’s paid for and already available in MHCLG’s AWS environment).
- Consider setting up AWS Origin Shield if you expect international traffic.
If you are using Azure, the Cloud Platform team should configure Cloudflare on your behalf.
Why?
Good caching reduces the risk of a Distributed Denial-of-Service (DDoS) impacting your website or service.
The origin access control prevents the CDN from being bypassed and traffic going directly to the origin servers, where they could be quickly overwhelmed by a DDoS attack. By implementing the control as an AWS WAF rule, traffic does not go to your origin servers. AWS scalable infrastructure handles it instead.
Third-Party Assets
Should Do
Unless you have a valid use case, do not use web assets hosted by a third party, particularly JavaScript such as the jQuery CDN. Using these introduces a vulnerability to users of your service that you cannot control. It also slows down your site.
Content Security Policy
Should Do
Content Security Policy (CSP) is one security header that tells browsers where a website should be loading resources and which resources it should be loading.
Follow these steps to configure:
- Enable CSP in “Report-Only” mode by setting the Content-Security-Policy-Report-Only header and enable the reporting mechanism.
- Review the browser developer console and use those to tune the CSP configuration.
- Change the header to Content-Security-Policy so that browsers can prevent potentially malicious activity.
Why?
Suppose an adversary discovers a vulnerability, such as cross-site scripting (XSS). In that case, they could include content or links to their malicious website. CSP helps prevent this by reducing the successful options available to an attacker.
Implement security.txt
Should Do
See vulnerability disclosure for information on how to configure.
You can find an example of implementing a redirect using Lambda@Edge in the [alphagov/aws-lambda-at-edge-examples] GitHub repo.
You can check the configuration using https://findsecuritycontacts.com/query.
Why?
A security.txt file helps malware or security researchers contact the Cyber Security team if there’s an issue found on the site.
Web Application Firewall
Should Do
Make it more difficult to exploit a weakness in your service which could cause you an incident by enabling a Web Application Firewall (WAF).
If you have dynamic content that takes user input, you should enable AWS WAF and apply appropriate rules.
Even if you do not have dynamic content, a WAF (even one with no enabled rules) can be helpful if you have ever have an incident in future by allowing for quick configuration.
Make sure you test after enabling WAF rules so they do not impact usability.
See more information on the use a web application firewall (WAF) page.
Vulnerability Scanning
Should Do
Find out about potential weaknesses early.
Sign up to NCSC’s Web Check service with your gov.uk email address to have NCSC scan and report common findings to you.
Use SSL test to check your Transport Layer Security (TLS) settings (formerly known as SSL or Secure Sockets Layer). Tick the “Do not show the results on the boards”.
See more about managing third-party dependencies.
Why?
Vulnerability scanning gives you an insight into what common weaknesses are present in your website or service; this may allow you to patch or mitigate the weakness before it’s exploited and becomes an incident.
Usage Analytics
Could Do
Consider using server analytics instead of remote analytics.
If you use remote analytics and handle sensitive data, such as user login, you should not include the remote JavaScript (as is the case with Google Analytics) on those paths.
Why?
Remote analytics can introduce a vulnerability to your service and requires relaxing the content security policy. It can also slow down the site for users with slow devices or where they have low bandwidth.