This took me a second to understand: The scenario in question has Protected Site A vulnerable to an XSS attack, but protected from it due to their CSP not allo

This took me a second to understand: The scenario in question has Protected Site A vulnerable to an XSS attack, but protected from it due to their CSP not allowing scripts from foreign domains (only trusting scripts from `trusted.example.com`). This is what CSP is for: it's not for what you expect to serve, it's for protecting against what you don't expect to serve. In the theoretical attack content-addressable scripting could open up, the user visits Malicious Site B, which loads a malicious script with the hash `abad1dea`. The owners of Malicious Site B use their XSS attack to insert the (simplified) HTML `<script src="https://trusted.example.com/payload.js" https://trusted.example.com/payload.js" hash="abad1dea">`. If Malicious Site B tried to insert a direct link to their payload at `malicious.example.com/payload.js`, it would be blocked due to the site's CSP - however, if the site trusted the fact that it's seen `abad1dea` from `malicious.example.com` as evidence that it could get the script from `trusted.example.com`, this would open up a vector allowing Malicious Site B to run the `abad1dea` payload in a way that would not be blocked by the CSP. This is why the UA still has to make the request, even though it already has the content. With the behavior that's been specced, a request will be made to `trusted.example.com` which will either 404 or give a different script, causing the XSS attack to be blocked by the page's CSP.