This is somewhat of a bug-fix, but it's a web-exposed bug fix which deserves full web platform security review, so we're using the Intent to Ship process. When we initially shipped the Speculation-Rules header, we reused much of the architecture from the <script type=speculationrules> implementation, and thus it was blocked by CSP policies that blocked <script> elements. This has caused some friction among web developers adopting the Speculation-Rules header, who expected CSP to only apply to <script>s. After consulting with Google and Chrome security teams, we realized our initial implementation was a mistake, as CSP's script policies are meant to protect against injection of scripts into HTML, and the CSP threat model doesn't relate to HTTP headers. As such, we're updating the integration between speculation rules and CSP so that CSP only applies to <script type=speculationrules>, and not to the Speculation-Rules header.
When we initially shipped the Speculation-Rules header, we reused much of the architecture from the <script type=speculationrules> implementation, and thus it was blocked by CSP policies that blocked <script> elements. This has caused some friction among web developers adopting the Speculation-Rules header, who expected CSP to only apply to <script>s. After consulting with Google and Chrome security teams, we realized our initial implementation was a mistake, as CSP's script policies are meant to protect against injection of scripts into HTML, and the CSP threat model doesn't relate to HTTP headers.
Explainers: https://wicg.github.io/nav-speculation/speculation-rules.html#security-xss