Static caching compatible Content-Security-Policy nonce values

[jamesmacwhite]

Since Craft CMS 5.3, you can set headers such as Content-Security-Policy in the main application app.config file. This works great, given Craft Cloud is serverless and you don't need to use a plugin/module.

For maximum security, policies like script-src should use a server side generated random nonce values to allow execution of required inline JavaScript where the generated value is added to all inline JavaScript rather than downgrade security by using unsafe-inline, meaning any inline <script> could be executed. This can pose an XSS risk, if such a vulnerability is found. It could lead to the execution of unknown JavaScript code being possible.

The static caching feature of Craft Cloud will potentially cause issues with trying to implement unique nonce values because the generated nonce value is likely to be cached and served across many requests until refreshed. This would be against the principle of the requirements given the nonce value should be unique and served only once before the next request.

I'm posting this as a potential discussion area for a hardened Content Security Policy implementation that works for Craft CMS/Craft Cloud. It would be nice if there was a Craft method that could generate a nonce value as part of the core class reference, in addition for Craft Cloud it would be ideal to maintain static caching functionality.

Potentially a similar principle to CSRF with async handling, but this has further complexity given the HTTP header aspect.

[timkelty]

Oh, I love it!
I haven't had a ton of real-world experience with this, so reading up on it here https://content-security-policy.com/nonce/

I'm I'm reading correctly, there are a couple ways to approach it:

1. use hash vs nonce (thus cacheable) https://content-security-policy.com/hash/

2. provide a nonce at the gateway level

3. is easy, but lets talk about 2:

To make this work with static caching, we need this to be provided at the gateway-level, which means we would need to parse the response and swap out some kind of token for the nonce.

We could come up with our own token format…but – since our gateway already (unofficially) supports the ESI 1.0 spec, it seems like a good standards-based way to do this would be with ESI variables, e.g.:

<esi:vars>
<script nonce="$(HTTP_NONCE)">
	doWhatever();
</script>
</esi:vars>

[andrewfairlie]

Being able to do something like nonce="{{ cloud.nonce() }}" would be a lovely developer experience.

The extension could presumably fall back to generating a local dev friendly nonce, but if it can do the logic behind the scenes to make <esi> stuff generate/use the correct nonce whilst still be static 🤯