[iamkonstantin]

What is a rendering engine with CSP in mind?

The server can, at best, set the correct CSP header. It’s a validation performed entirely in the browser. Even the best intended rendering from the server can’t prevent CSP violation attempts when the client is executing some kind of script. That’s why even frameworks like Vue and React need a correctly configured CSP.

[the8472]

Rewrite the inline styles/scripts at build times to separate files, generate the appropriate script/style elements, compute the appropriate CSP directive.

The renderer could rewrite

   <div onclick="foo()">

to

   <div id="handler-Oov1to1o">
   <script integrity="sha256-b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c" src="generated-content/handlers.js"></src>

   // handlers.js:

   document.querySelector("handler-Oov1to1o").addEventListener(() => foo())
   // [...] more handlers here

   // HTTP header

   content-security-policy: script-src sha256-b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c <...>;
   

(the boilerplate can be amortized over many such handlers)

Or at least use 'unsafe-hashes' and compute the hashes for onclick handlers and the like and include those in the CSP.

Separation of style/scripts/content has been encouraged for a long time, I don't know why people are walking it back. But if they insist then templates could also be structured more like a multipart document where those aspects sit in separate parts of the document.

As long as you do any of those when the template renderers are compiled then only scripts whitelisted at buildtime will be executed and scripts injected by dynamic content will get blocked.

[iamkonstantin]

Thank you for clarifying, now I understand what you mean. I think we’re on the same page! I like separating assets as they can also have a very different lifecycle than the structure / content of a page.