The nonce
attribute allows you to “whitelist” certain inline script
and style
elements, while avoiding use of the CSP unsafe-inline
directive (which would allow all inline script
/style
), so that you still retain the key CSP feature of disallowing inline script
/style
in general.
So the nonce
attribute is way to tell browsers the inline contents of a particular script or style element weren’t injected into the document by some (malicious) third party, but were instead put in the document intentionally by whoever controls the server the document is served from.
The Web Fundamentals Content Security Policy article’s If you absolutely must use it ... section has a good example of how to use the nonce
attribute, which amounts to the following steps:
For each request your Web server receives for a particular document, have your backend make a random base64-encoded string of at least 128 bits from a cryptographically secure random number generator; e.g., EDNnf03nceIOfn39fn3e9h3sdfa
. That’s your nonce.
Take the nonce generated in step 1, and for any inline script
/style
you want to “whitelist”, make your backend code insert a nonce
attribute into the document before it’s sent over the wire, with that nonce as the value:
<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">…</script>
Take the nonce generated in step 1, prepend nonce-
, and make your backend generate a CSP header with that among the values of the source list for script-src
or style-src
:
Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'
So the mechanism of using a nonce is an alternative to instead having your backend generate a hash of the contents of the inline script
or style
you want to allow, and then specifying that hash in the appropriate source list in your CSP header.
Note that because browsers don’t (can’t) check that the nonce value sent changes between page requests, it’s possible—though totally inadvisable—to skip 1 above and not have your backend do anything dynamically for the nonce, in which case you could just put a nonce
attribute with a static value into the HTML source of your doc, and send a static CSP header with that same nonce value.
But the reason you’d not want to use a static nonce in that way is, it’d pretty much defeat the entire purpose of using the nonce at all to begin with—because, if you were to use a static nonce like that, at that point you might as well just be using unsafe-inline
.
As far as which elements are “nonceable”: The CSP spec currently restricts browsers to checking nonces only for script
and style
elements. Here are the spec details:
In https://w3c.github.io/webappsec-csp/#match-element-to-source-list, see step 2:
If type is "script" or "style", and § 6.6.3.1 Is element nonceable? returns "Nonceable"…
At https://w3c.github.io/webappsec-csp/#is-element-nonceable, the Is element nonceable? algorithm itself doesn’t check just for script
/style
elements; but the only place the spec calls that from is the part cited above, which restricts it to script
and style
. So if you put a nonce on any other element, the current spec requires browsers to ignore it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With