Gatsby Content Security Policy (CSP)

[m-allanson]

Summary

By default Gatsby generates a couple of inline <script> tags and one (or more?) inline <style> tags for each page.

This is problematic when creating a Content Security Policy (CSP) for your site, as the inline scripts mean script-src 'unsafe-inline' needs to be configured for your CSP. This in turn undoes some of the benefits of a CSP.

This issue is tracking improvements to using Gatsby with a CSP.

Useful links:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src
• https://bitbucket.org/atlassianlabs/csp-webpack-plugin (possibly useful for reference)

Related issues:

• Generate inline script SHA for Content-Security-Policy #3427
• [Question v2] Gatsby script loader in external file #8025
• Possible to add a noonce option for scripts? #3746
• Allow Gatsby to run with a CSP without unsafe-inline. #3758

Basic example

Quoting @chuckharmston from issue #3758:

There are two ways to permit this:

1. By allowing generated assets to be loaded as external assets, so origins can be used to control this.
2. By using strict-dynamic and hashes of the content of each generated file or inline resource. This provides slightly better security, but is also more complex and rigid. Ideally in this case, the generated CSP is inserted as a <meta> tag and the same CSP is inserted into gatsby-plugin-netlify's generated _headers file.

Motivation

Adding a Content Security Policy can be a useful safeguard for your site, Gatsby should provide options for people using CSPs.

[eduards]

I just started to look into this issue. I'd like to use Gatsby for our public web projects but the missing CSP support is a blocker for us. I'm happy to invest some time to look into this but would appreciate if someone could point me into the right direction as I'm brand-new to the codebase 🙈

[lucasjohnston]

Not sure how much help I can be, but seconded ☝️

[DSchau]

cc @xjamundx, you'd be interested in this too, correct? With the additional consideration of nonce if I recall, correctly?

[kristiehowboutdat]

Happy to help as well, but new to the repo - what lifecycle APIs would be best to use?

[travi]

in addition to the issues that need to be improved with gatsby itself, i'm curious how gatsby plugins might be addressed for similar concerns. have others already considered what would be needed beyond core?

[mattburrowsmonzo]

Hi all,

My colleague @eduards and I looked into getting CSPs working with Gatsby last week and wanted to share our progress.

The changes that we made were to the static-entry.js file. You can see what we did in this GitHub comparison view.

We set out to get CSPs working by hashing inline scripts and styles by adding the hashes to a meta tag that we add to the head. We found inlined scripts and styles by extracting them from the following objects in the static-entry.js file:

• headComponents
• preBodyComponents
• postBodyComponents

We are working out whether they are inlined scripts / styles by checking for either the “script” or “style” type and the “dangerouslySetInnerHTML” property on the props key

With these simple changes we managed to get CSPs working with the httpEquiv="Content-Security-Policy" meta tag.

From getting the proof of concept (POC) working, we came to the conclusion that making the changes in this file wouldn’t be the best way to implement CSPs. And instead would like some advice about implementing this as a plugin (if this is the right approach).

A few questions to help us on the way:

• If writing as a plugin, how can we make sure it picks up all the inline styles / scripts? Is there a Gatsby lifecycle hook that we can tap into that also allows us to access the headComponents, preBodyComponents and postBodyComponents?
• Implementing a strict CSP means a lot of themes will not work as they rely on style attributes on elements which are blocked. This is something we encountered when implementing CSPs in static-entry.js. Are there any other edge cases that we might be missing?
• If this should be a core feature, are there any examples you can recommend for configuring CSPs?
  • As well as picking up inline styles / scripts users should also be able to pass in config so they can whitelist domains, include data: images and other things they might want to configure
  • Various pages might have different CSPs so how can we implement it on a page by page basis?
• This solution covers implementing CSPs via a meta tag, what is the best approach for headers?
  • Is it to update the netlify headers plugin?

[thomkrupa]

Hey, internally we've been using a custom plugin for this. I decided to open source it, maybe it will help some of you.

https://github.com/bejamas/gatsby-plugin-csp

It generates hashes for inline scripts and styles which means it sets strict policy by default.

[mattburrowsmonzo]

@thomkrupa looks like we both had the same idea! 😂

I created a repo last night with the same name to do pretty much the same thing -> https://github.com/mattjburrows/gatsby-plugin-csp

[dsebastien]

@thomkrupa @mattburrowsmonzo, thanks for sharing!
Your solution does help, but I'm still having issues with gatsby-image that generates inline styles.

When I use gatsby develop it works fine (with CSP enabled), but it fails with gatsby build

For now I'll have to keep unsafe-inline there :(

[dsebastien]

By the way, at the moment I'm using gatsby-plugin-netlify (https://www.gatsbyjs.org/packages/gatsby-plugin-netlify/) to add security-related headers and it would be great to be able copy the CSP generated by your plugin to the "_headers" file generated by gatsby-plugin-netlify.

I'm trying to do it now by parsing the generated "public/index.html", but I'm guessing that there could be an easier solution (e.g., if you plugin wrote the raw CSP content somewhere or made it available somehow for other Gatsby plugins to use :)

Here's my current solution: DeveloPassion/website@c31120c

[thomkrupa]

hey @dsebastien, thanks for your feedback! Feel free to create an issue(s) -> https://github.com/bejamas/gatsby-plugin-csp/issues so we can track the progress on them.
Gatsby-image issue is something I will definitely look into.

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[dsebastien]

ping. Don't let this one get forgotten please :)

[dsebastien]

Hey everyone.

I'm also facing this issue with the google analytics plugin. Initially, I thought that I could simply add a 'sha256-...' entry to my script-src, but the value changes from page to page. That plugin should allow to pass a nonce so that we can whitelist it through the CSP.

[m-allanson]

Question for folks - is this something that should be moved in to core? What should be optional, what should be enabled for everyone? Is this something that always needs to be configured, so people would be better served by using the https://github.com/bejamas/gatsby-plugin-csp plugin?

[kripod]

Is it possible to support the webpack-recommended way of handling nonces out of the box? Each page should have a __webpack_nonce__ defined, which would be great for e.g. CSS-in-JS libraries offering dynamic style injection.

[hades200082]

Unfortunately that doesn't solve the issue of the nonce needing to be dynamically generated for each page request... without dynamic generation the nonce becomes meaningless and useless as a security measure.

[hades200082]

Ideally these are the criteria that should be met for this...

1. All Gatsby generated inline styles and inline scripts (including those from custom components) should be detected and their hashes added to the relevant CSP section automatically
2. The option in plugin options to configure any/all CSP options for allowed hosts, additional hashes, etc.
3. CSP served as HTTP headers (not meta tag)

https://github.com/bejamas/gatsby-plugin-csp seems to cover #1 and #2 but cannot do #3.

[JustFly1984]

@wardpeet please pay attention to this issue.
In our case we have our gatsby.js projects built with github actions and deployed to AWS S3 bucket, and invalidating CloudFront distribution. We have AWS edge lambda attached to each response, generating headers, including CSP header.
We had a plan to generate unique nonce on each response, cos we are setting up analytics and other 3rd party apis, and this is a real bummer to read this issue.

We need to handle private user data on our websites, and A+ security is our goal to bring clients onboard.

Currently I'm following https://eqxtech.com/engineering/our-lambda-dance-gets-more-serious/ idea, and had another idea about substituting some constant nonce in response html with regexp.

Is it possible to setup dummy CSP nonce to the scripts and styles at build time?

[viniciuspardini]

Ideally these are the criteria that should be met for this...

1. All Gatsby generated inline styles and inline scripts (including those from custom components) should be detected and their hashes added to the relevant CSP section automatically
2. The option in plugin options to configure any/all CSP options for allowed hosts, additional hashes, etc.
3. CSP served as HTTP headers (not meta tag)

https://github.com/bejamas/gatsby-plugin-csp seems to cover #1 and #2 but cannot do #3.

Maybe for #3 the workaround is to make something similar to what they are doing here: https://github.com/DeveloPassion/website/commit/c31120ccccefed43c266c8ef862ec696bd36c7a8. A process that at build time, get the meta tag from the index.html file, but instead of adding it to a configuration file, add the directive to the web server, or in my case, to the Lambda@Edge function. I didn't test it yet, but I'll work on that.

[larowlan]

FYI, for those proposing using a meta element for CSP, it is not supported by Chrome, so if you're using the CSP plugin only, without setting the header - it is likely your CSP rules aren't working in Chrome

https://caniuse.com/mdn-http_headers_csp_content-security-policy_meta-element-support

[larowlan]

Actually, I think that Can I use may be incorrect for that, because testing in Chrome is indicating that it works

[larowlan]

I opened mdn/browser-compat-data#6998 to discuss updating ^

[lee5i3]

This is still an issue for us, as we are using Cloudfront to host our site using S3, so we cannot use a plugin to set headers

We have a lambda that sets the CSP header for us, so we cannot have any inline, right now we have no choice but to keep using unsafe-inline

[nop33]

I've managed to make my site work without having to add script-src 'unsafe-inline' by removing inline scripts and styles inserted by Gatsby:

// Remove inline scripts and styles inserted by Gatsby
export const onPreRenderHTML = ({
  getHeadComponents,
  replaceHeadComponents,
  getPostBodyComponents,
  replacePostBodyComponents
}) => {
  if (process.env.NODE_ENV !== 'production') return
  replaceHeadComponents(
    getHeadComponents().filter(
      (component) =>
        !['gatsby-image-style-script', 'gatsby-image-style-noscript', 'gatsby-image-style'].includes(component.key)
    )
  )
  replacePostBodyComponents(
    getPostBodyComponents().filter((component) => !['script-loader', 'chunk-mapping'].includes(component.key))
  )
}

All was well, until I noticed that this breaks the redirection from mydomain.com/index.html to mydomain.com. When I load mydomain.com/index.html, the page loads correctly for a split of a second, and then all HTML content within the #gatsby-focus-wrapper element gets removed:

<div id="___gatsby">
    <div style="outline:none" tabindex="-1" id="gatsby-focus-wrapper"></div>
</div>

The problem was that I removed the script-loader...

The only solution for now is to degrate my CSP by adding the unsafe-inline back again...

[AienTech]

2022 and no actual fixes here?

[kaushalyap]

@wardpeet any plans to address this issue? It has been years.

[justinh00k]

2023 checking in

[NicholasRowe]

2024 knocking

[Cynocracy]

Initially trying to fight against React hydration's dislike of nonce tags, we eventually pivoted to generating the sha256 sums for our production build with the following script:

import { createHash } from "crypto";
import { readFile } from "fs/promises";
import { join } from 'path';
import { parse } from 'node-html-parser';

const computeHashes = (indexHtml) => {

  let scriptHashes = []; // other hashes can be added here if it's not in index.html directly
  for (let s of indexHtml.querySelectorAll('script')) {
    if (s.innerHTML!="") {
	 scriptHashes.push(
      `'sha256-${createHash("sha256")
               .update(s.innerHTML).digest("base64")}'`
      );
    }
  }

  return scriptHashes;
};

export const updateCSP = async () => {
  const indexHtml = 
        await readFile(join(process.cwd(), 'public', 'index.html'), "utf-8"); // or this could be expanded to include new sources
  const scriptHashes = await computeHashes(parse(indexHtml));
  console.log(scriptHashes);
};

await updateCSP();

Our build process looks like (gatsby build) -> (generate SHAs) -> (add SHAs at CSP-header to static file server) -> (run server)

Hopefully this helps someone else looking to avoid unsafe-newline!
Stay safe out there :)

[ArmanNisch]

2023 and no actual fixes here?

[hades200082]

I've long since moved away from Gatsby to NextJS. Their new direction with React server components looks very promising for handling csp properly.

[tackc]

Bump...this issue is effecting my website also. We host using S3 / CloudFront. My security team is NOT happy that 'unsafe-inline' is enabled for the script-src directive. Really haven't found a great solution to resolve this issue yet

[AKlaus]

OK, below is a Node.js script to calculate all the hashes for all produced *.html files.
But now there's a dilemma:

• Either manually set the hashes required by each file (not using gatsby-plugin-csp plugin) or
• Add all the hashes into the gatsby-plugin-csp config and re-publish the project. Though this will lead to ruining webpackCompilationHash, as it'll be changed (see Can you opt-out of webpackCompilationHash (to improve Netlify build times) #15872).

Either way the solution feels clunky.

import { createHash } from "crypto";
import { Parser } from "htmlparser2";
import fs from "fs";

const TARGET_FOLDER = path.join(path.resolve(), 'public');

// The list of all hashes for inserting later via `gatsby-plugin-csp` settings
let scriptHashes = [];
// Iterates through the list of HTML files to calculate all hashes
// Note, I omitted the body of `getHtmlFiles()` method
getHtmlFiles(TARGET_FOLDER).forEach(file => {
	scriptHashes.push(...getShaFromTags(file, 'script'));
});

function computeHash(text) {
	return `'sha256-${createHash("sha256").update(text).digest("base64")}'`;
}
// Return an array of hashes for <inputFilePath> file and the content of all instances of <tagName> tag
function getShaFromTags(inputFilePath, tagName) {
	console.log(`Getting '<${tagName}>' from ${inputFilePath}`);
	try {
		const fileContents = fs.readFileSync(inputFilePath, { encoding: 'utf-8' });
		let hashes = [];

		let inScriptElement = false;

		const parser = new Parser(
			{
				onopentag: (name, _) => {
					if (name === tagName)
						inScriptElement = true;
				},
				ontext: (text) => {
					if (inScriptElement) {
						hashes.push(computeHash(text));
					}
				},
				onclosetag: (tagname) => {
					if(tagname === "script")
						inScriptElement = false;
				}				
			},
			{ decodeEntities: true }
		);

		parser.write(fileContents);
		parser.end();

		let uniqueHashes = [...new Set(hashes)];

		return uniqueHashes;
	} catch (err) {
		console.error(`Could not retrieve '<${tagName}>' from ${inputFilePath}`);
		throw err
	}
}