Besides whether it is a real security risk, this is useful information if you have to work with a security department. In particular, there are corporate environments where certain CSP settings would require approval or are simply not possible.

An article focused on "htmx requires more CSP exceptions than you might be comfortable with" would be great. This is not that article.

> If you allow random users to write arbitrary unsanitized HTML into other users’ pages, you have already lost

Not really. The whole point of CSP is that, even if someone manages to inject arbitrary HTML into your page due to a bug or oversight, you can prevent injected scripts from running entirely, severely limiting what an attacker can do.

I'm surprised at the amount of comments on this post that seem to be completely clueless about CSP.

> if someone manages to inject arbitrary HTML

If they can, why wouldn’t it be inline <script>?

Because CSP can be configured to block inline scripts.

The syntax to allow inline scripts is even "unsafe-inline" to emphasize that you are entering the danger zone.

serving html with string concatenation is just like creating sql statements with string concat.

At least thats how I see it. Ideally you'd use something similar to prepared statements, just for html templates.

CSP is a backstop that—when configured properly and used alongside restraint in how you script—can minimize some of the worst consequences of injection.

It doesn’t wash your hands clean of the responsibility to restrict what kinds of content users can inject into served pages.