CODEWITHSUNDEEP
webpacknuxt.jsaws-amplifycontent-security-policy
rvaneijk
rvaneijk

Reputation: 663

How to add a nonce for script and style tags to avoid 'unsafe inline' CSP header field?

Context description I am using AWS Amplify to deploy my static web page.

The custom security headers are applied in the deployment through a configuration file customHttp.yml (https://docs.aws.amazon.com/amplify/latest/userguide/custom-headers.htm)

I include the customHttp.yml file in a .nuxtignore file to prevent triggering a rebuild of the webpack files if only the custom headers change. However, this only works locally, not on the server side in the deployment process.

Problem description AWS Amplify does not use the .nuxtignore file in the deployment process. Therefore webpack files are rebuilt every time, resulting in a different hash value that I would need to include in the CSP header fields script-src and style-src. But since triggering a rebuild to apply a modification to customHttp.yml results in a new has value for the jetpack file(s), we never know the correct value upfront.

Suggestion for solving the problem A nonce would (if static) solve my use case. For example by defining the nonce in the nuxt.config.js file. By including the nonce in the webpack rebuild, I would be able to refer to the static nonce in the CSP header fields because the value would not change.

For example - nuxt.config.js:

generate: { script-nonce: 'nonce-457bb2Bb06E44Ab5aa9996Ed1a34b26F', style-nonce: 'nonce-[ ADD A VALUE HERE ]' }

I realize that the Content Security Policy specification calls for a unique nonce value each time the server transmits a CSP-policy, But for this use case, a static nonce would be my preferred suggestion.

Upvotes: 2

Views: 6074

Answers (1)

granty
granty

Reputation: 8496

Using a "static nonce" is the same as 'unsafe-inline' usage. You can only fool some online CSP testing tool that they don't recognize that your 'nonce-value' is static.

Classic XSS is when it is possible to insert and execute code like <script>alert('XSS')</script>. Without 'unsafe-inline' such inline script will be blocked.

But with the "static nonce" attacker just injects <script nonce="static_nonce">alert('XSS')</script>, so you have exactly the same vulnerability as when 'unsafe-inline' is allowed.

While with dynamic nonce attacker can see curent nonce, but can't predict next one. So he does not knov which nonce value to use, because his XSS will be injected only after page reloads.

Pls see With CSP enabled vis amplify.yml results in Errors #612, maybe you find some clue there (link to Lambda@Edge function and Amazon CloudFront at the bottom).

Upvotes: 6

Related Questions