Removing 'unsafe-inline' as 'script-src' from Content Security Policy when using Firebase

Question

I would like to remove the 'unsafe-inline' in the 'script-src' from the Content Security Policy of my web app, and increase it security. Unfortunately though, Firebase seems to require it in order to work (I'm using Firebase auth and Firestore).

How do I go about creating a more secure web app? I read about using a nonce, but I'm not sure how I can specify to the firebase script (I'm using the Web modular via npm package in a Nextjs app).

Thanks

Answer 1

The nonce attribute lets you “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' script/style in general.

So the nonce attribute is a way to tell browsers that 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 of 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—tthough totally inadvisable—tto 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 that 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 specification currently restricts browsers to checking nonces only for script and style elements. Here are the specification 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.