Subresource Integrity and Nonce Values - html

Question

Currently, for our web application, we are generating nonce values to attach to script tags. I have recently found out about Subresource Integrity and considering that we're using a CDN (as most examples reference), I was curious if this was something my web app should use.
Is there ever a case for both nonce and integrity attributes to be used? Is one better than the other? Or, do they support multiple use cases entirely?
Thanks

Answer 1

They support different use cases and you can use both.
Nonce instructs the browser to execute only <script> elements which have the same nonce value set in the CSP header.
nonce-*
A cryptographic nonce (only used once) to whitelist scripts. The server must generate a unique nonce value each time it transmits a
policy. It is critical to provide a nonce that cannot be guessed as
bypassing a resource's policy is otherwise trivial. This is used in
conjunction with the script tag nonce attribute. e.g.
nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV
So let's say your application set a Content-Security-Policy header like script-src'nonce-r4nd0m'; then the script at good.com/good.js will be executed because the nonce value is the same.
<script nonce="r4nd0m" src="//good.com/good.js">
What happens if an attacker compromises good.com and add a malicious script to good.js? That your web application still allows the execution of that script because the check is made on the nonce value not on the script content. So you need also to be sure that the content of good.js remains the same.
Here integrity attribute is involved. It implements Subresource Integrity and tells to the browser to run resources only if the computed hash matches with the one stored in the integrity attribute.
Subresource Integrity (SRI) is a security feature that enables
browsers to verify that resources they fetch (for example, from a CDN)
are delivered without unexpected manipulation. It works by allowing
you to provide a cryptographic hash that a fetched resource must
match.
So let's suppose the first time you included the script in the web app, the content of the script was safe and the integrity value was X. Then you added integrity="sha384-X" to the script element as follows.
<script src="//good.com/good.js"
integrity="sha384-X">
The attacker modifies good.js so the resulting hash of the modified script becomes Y. The browser doesn't run the script because the computed hash (Y) and the required hash (X) don't match.
I think you can combine both like this.
<script nonce="r4nd0m" integrity="sha384-X" src="//good.com/good.js">