Issue sheet

Document location	/nhsbsa-digital-playbook/security/content-security-policy/
Title	Content Security Policy
Author	Professional Lead Software Development
Owner	Security Operations Manager
Issued to	DDaT
Approved by	DA
Approved	30 June 2022
Last reviewed	30 June 2022
Next review due	30 December 2022

Revision history

Version	Date	Amended by	Approved by	Details
1.0	24 June 2022	PT	AW	Initial release
1.1	17 September 2022	PT	AW	CSP `navigate-to` directive removed from CSP L3 working draft

A Content Security Policy (CSP) helps prevent unwanted content from being injected/loaded into your webpages. This can mitigate cross-site scripting (XSS) vulnerabilities, clickjacking, formjacking, malicious frames, unwanted trackers, and other web client-side attacks.

If you want to learn how CSP works, check out:

• Web.dev guide to CSP
• Content Security Policy quick reference guide
• W3C Content Security Policy specification
• MDN Content Security Policy reference
• Google’s guidance on CSP
• OWASP CSP Cheat sheet

Start early

Developing a site with CSP from the outset is much easier than retrofitting CSP to an existing site.

CSP Header

Sending the standard Content-Security-Policy header as well as earlier X-Content-Security-Policy or X-Webkit-CSP headers causes unexpected behaviours on some browsers. Avoid using the deprecated X-* headers.

Chrome dev-tools hides the X- style CSP response headers in preference to the standard Content-Security-Policy, even when they are sent. Use this curl command to test whether your site is sending the deprecated headers:

curl --head <URL>

CSP levels

CSP is an evolving standard, and with each new release comes tighter controls to protect users. These are referred to as CSP Levels. We aim to provide as secure an experience as possible with the browsers available to our users.

Design to Content Security Policy level 2 and above. At the time of writing, all modern browsers support Level 2. IE 11 supports parts of Level 1 and it relies on the deprecated and dangerous X-Content-Security-Policy. It can therefore be safely ignored from scope of the CSP.

Browser support

To check CSP level support in browsers refer to the CanIUse website:

• CSP Level 1
• CSP Level 2
• Browser support for CSP Level 3 is currently undocumented on CanIUse.

Cross reference our supported browsers to get a clear understanding of which Level we must support.

CSP Evaluator

To check what your CSP states at the different levels, and what the security implications are, use the CSP Evaluator from Google.

Be sure to check your CSP at level 2 and 3 (referred to as Versions in the evaluator)

Hash and nonce

Some of the CSP directives can use a hash or a nonce value. A hash is a SHA hash of a resource such as a script file. A cryptographic nonce is a unique value that is generated once per request. Using a hash (preferred) or nonce will improve resilience to attacks. If you use a directive that supports them, then you should do so.

If using a nonce, be sure to understand the security implications and talk to our security team.

Framework support

Node.js

Helmet-CSP is an extension to the Helmet.js security library. It will generate dynamic CSPs for you through configuration, and has support for nonces.

Example Expess.js/Helmet.js configuration that’s aligned with the BSA HTTP Security Headers:

import * as helmet from 'helmet';

...

// optional nonce middleware
app.use((req, res, next) => {
  res.locals.scriptNonce = Buffer.from(v4()).toString('base64');
  next();
});

const {
  'object-src': objectSrc,
  'script-src': scriptSrc,
  ...defaultDirectives
} = helmet.contentSecurityPolicy.getDefaultDirectives();

app.use(
  helmet.contentSecurityPolicy({
    directives: {
      ...defaultDirectives,
      'default-src': ["'none'"],
      'form-action': ["'self'"],
      'frame-ancestors': ["'none'"],
      'plugin-types': ["'none'"],
      'prefetch-src': ["'none'"],
      'script-src': [
        ...scriptSrc,
        (req, res) => `'nonce-${res.locals.scriptNonce}'`,
      ],
      'style-src': ["'self'"],
    },
  })
);
app.use(helmet.crossOriginEmbedderPolicy());
app.use(helmet.crossOriginOpenerPolicy());
app.use(
  helmet.crossOriginResourcePolicy({
    policy: 'same-site',
  })
);
app.use(helmet.dnsPrefetchControl());
app.use(helmet.frameguard());
app.use(helmet.hidePoweredBy());
app.use(
  helmet.hsts({
    maxAge: 31536000,
  })
);
app.use(helmet.ieNoOpen());
app.use(helmet.noSniff());
app.use(helmet.originAgentCluster());
app.use(
  helmet.referrerPolicy({
    policy: 'strict-origin-when-cross-origin',
  })
);
app.use(helmet.xssFilter());

Java/Spring

Spring-security only has support for a static CSP. This is insufficient for generation of a nonce/hash. See this article for details of how to support CSPs with dynamic nonce generation, substitution in the CSP and usage in an HTML template. A similar technique could be used for hashing.

Inline scripts

Try to avoid inline scripts.

If your application uses inline scripts such as the usual Google Analytics and/or Google Tag Manager snippets:

• Extract the inline script into file hosted by your service and allow that to load using the ‘self’ value

  otherwise…

• Ese a nonce-* value and add a nonce attribute to the inline script
  You may need to pass the nonce value downstream to the Google scripts loaded from the inline script.
  See this article for further detail: Use Tag Manager with a Content Security Policy

Reporting

While developing a CSP it can be useful to use the Content-Security-Policy-Report-Only header. The browser will report violations of the CSP without breaking the web application. Fix the policy or the application before switching to use the Content-Security-Policy header.

It is a good idea to release the CSP in report only mode to gain the confidence that no issues have been found in the wild.

Even after switching to an enforcing CSP, it is useful to receive reports. This will alert to any problems that are introduced, or to attacks being made in the wild. Add the report-uri and report-to directives to the CSP (see below).

Example CSP

This is an example CSP to use as an initial basis for development.

Note:

• Use of Google Analytics and Google Tag Manager: Remove if not required
• Use of nonce: Remove if not supported in your framework

default-src 'none';
frame-ancestors 'none';
base-uri 'self';
form-action 'self';
plugin-types 'none';
prefetch-src 'none';
script-src 'self' 'nonce-{nonce}';
style-src 'self' 'nonce-{nonce}';
img-src 'self' 'nonce-{nonce}' https://www.google-analytics.com https://www.googletagmanager.com;
font-src 'self' 'nonce-{nonce}' https://assets.nhs.uk;
connect-src 'self' 'nonce-{nonce}' https://www.google-analytics.com https://www.googletagmanager.com;
report-uri TBD;

MUST

SHOULD

COULD

SHOULD NOT

References

• W3C CSP specification
• MDN Content Security Policy reference
• Web.dev guide to CSP
• CSP with Google
• Google - Strict Content Security Policy
• Google - CSP Evaluator
• Google Developers - Using Google Tag Manager with a Content Security Policy
• Google fundamentals - Content security policy
• Content Security Policy - OWASP Cheat Sheet Series
• Content-Security-Policy
• Can I use… CSP
• Helmet-csp
• CSP On Reporting and Filtering

---

Improve the playbook

If you spot anything factually incorrect with this page or have ideas for improvement, please share your suggestions.

Before you start, you will need a GitHub account. Github is an open forum where we collect feedback.