Htmx does not play well with content security policy

I moved from PHP to GO

I brought the hate with me.

In all honestly you're allowed to not like a thing (or golfing). You carry on doing you and leave the go jobs to me ;)

The relevant thing here is that before, CSP would protect you even if you failed to sanitize an attacker-controlled input. Bringing in htmx allows the attacker to bypass CSP, and that hasn't been documented well before.

The htmx docs mention CSP in passing but don't explore the nuance that OP does.

If you allow random users to write arbitrary unsanitized HTML into other users’ pages, you have already lost, htmx or otherwise.

There are some good points here, but I think the author neglects to dig deeper and explain how you can mitigate some of these risks with htmx settings.

I've been using htmx with CSP for the past couple of weeks, and I do find that it expands attack surface in an unpleasant way, but I do still think it brings enough value that I'm willing to rely on other protections.

>That cors.php file contains the JavaScript payload, and also sets CORS headers so that the browser has access to it.

The following htmx settings should defeat this:

    htmx.config.selfRequestsOnly = true;
    htmx.config.allowScriptTags = false;
    htmx.config.allowEval = false;

>HTMX has functionality that automatically adds the correct nonce to inline scripts it retrieves. This is convenient, but totally breaks the security model of CSP with nonces.

Agreed, this seems like an anti-feature that completely subverts CSP.

>Of course, this is trivial to bypass: just close the div tag with and insert your payload outside of the element with the hx-disable attribute.

This is true, but it kind of glosses over the fact that you have to screw up a lot more to give the attacker complete control over the HTML. Usually you're not just executing attacker-controlled content as HTML. If you're using a templating system, the more likely vulnerability is that the attacker is limited to escaping an HTML attribute and adding extra one. That said, it's true that if you have a vulnerability that allows an attacker can escape one context, it's much more likely that they can escape them all.

>For these to work, the application has to allow evaluating dynamic code, using the CSP option unsafe-eval. However, allowing unsafe-eval immediately makes it possible to inject JavaScript using HTMX functionality.

I think this is the weakest point, as htmx works well without unsave-eval. I've been using it in my app without unsafe-eval. The features you lose are just convenience features for writing HTML that you can still achieve by subscribing to htmx events in JS. Yes, it means you have to write a little bit more JS, but it's much better than including unsafe-eval.

I wish that htmx would be a bit more CSP-friendly, but it's much better than other similar frameworks.