What’s the purpose of the HTML “nonce” attribute for script and style elements?

The nonce attribute lets you to “whitelist” certain inline script and style elements, while avoiding use of the CSP unsafe-inline directive (which would allow all inline script and style), so 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:

1. For each request your web server gets 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.

2. 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>
   

3. 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: browsers don’t (can’t) check that the nonce values which servers send actually change between page requests; and so, 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/style. So if you put a nonce on any other element, the spec requires browsers to ignore it.