[mtlynch]

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 </div> 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.

[bastawhiz]

> you have to screw up a lot more to give the attacker complete control over the HTML.

Isn't this just a XSS vulnerability?

[mtlynch]

What I mean is that imagine you have HTML like this:

    <div hx-disable><img src="foo.jpg"></div>

You might screw up and give the attacker a way to control the src attribute like:

    <div hx-disable><img src="//evil.com/bad.jpg"></div>

So, maybe unintentional behavior but still no xss.

And if you let the attacker inject double quotes, then they can escape the attribute and do something like this:

    <div hx-disable><img src="foo" hx-delete="/account" hx-trigger="load"></div>

In this case, htmx would still prevent the xss because hx-disable causes htmx to ignore the hx-delete attribute in the child element.

But if we assume the server fails to encode angle brackets too, then the attacker wins because they can terminate the hx-disable, as described in the post.

    <div hx-disable><img src="foo"></div><span hx-delete="/account" hx-trigger="load"></span>

But they're different levels of screwup. Accidentally letting the attacker control the value of the attribute is one level, letting them inject extra attributes is another level, and letting them inject extra HTML elements is another level.

Granted, if you're screwing up output encoding, you're likely going to grant the attacker the ability to inject elements at the same time that you allow them to inject attributes, but the defender has a bit more protection if they disallow or encode angle brackets in user input.

[bastawhiz]

> letting them inject extra attributes is another level, and letting them inject extra HTML elements is another level.

These are ultimately the same problem. "Letting" is the wrong word here—nobody intends to let an XSS happen. These are two scenarios I've encountered in my own work:

- You're doing custom rendering, like markdown, and the output isn't exhaustively sanitized

- You used triple braces in Handlebars (or the unescaped output syntax of your favorite templating language) and the code gets reused for something unrelated that shouldn't be using unescaped output.

"Screwing up output encoding" is an alarmingly common vulnerability. XSS is arguably one of the most (if not the most) common security vulnerability ever. That's not to say it's a problem with HTMX, but the CSP exists specifically for this reason and HTMX essentially acts as an interpreter that can run arbitrary instructions. It's definitionally a way to bypass the CSP in the face of an XSS where a traditional attack would have been otherwise blocked by the CSP.