v4 beta: settle/history restore copies style attributes and triggers CSP violations

[richardrigby]

Summary

HTMX v4 beta appears to copy style attributes during the settle phase of innerHTML swaps and history restore.

That results in calls equivalent to:

element.setAttribute("style", ...)

Under a strict CSP, navigation still works, but the browser logs repeated CSP violations.

Version

• htmx 4.0.0-beta1

CSP

Reproduced with a policy like:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-<N>' 'strict-dynamic';
  style-src 'self' 'nonce-<N>';
  style-src-attr 'unsafe-inline';
  img-src 'self' data:;
  font-src 'self';
  connect-src 'self';
  frame-ancestors 'none';
  object-src 'none';
  base-uri 'self';
  form-action 'self';

inlineStyleNonce does not help here because the violation is for style="" attributes, not <style> elements.

Reproduction

This reproduces most clearly on browser back/forward navigation with HTMX history enabled.

Typical pattern:

1. HTMX navigation swaps in content with hx-swap="innerHTML"
2. Old and new content contain matching element ids
3. Use the browser back button
4. Console logs repeated CSP violations for inline style application

Actual behavior

History restore and settle succeed functionally, but the console logs CSP violations from style-attribute writes.

Expected behavior

Normal HTMX settle/history behavior should not require temporary style="" attribute writes in a way that breaks strict CSP.

Notes

From reading the v4 beta source, HTMX appears to temporarily copy old attributes onto matching new elements during settle, including style, then restore them later.

In our app, this specific path stopped when we set:

{
  "morphIgnore": ["data-htmx-powered", "style"]
}

That suggests HTMX already has a partial escape hatch, but the default behavior still triggers CSP violations and the intended CSP-safe configuration is not clear.

Questions

• Is morphIgnore: ["style"] the intended workaround for strict CSP?
• If yes, could that be documented explicitly?
• If not, is there a preferred HTMX-supported way to keep settle/history restore CSP-clean?

Suggested fix

One of these would help:

• skip style attribute copying by default during settle/history restore
• add a dedicated config for attributes ignored during settle
• document the official CSP-safe configuration if one already exists

[MichaelWest22]

When I test the repro with chrome with that strict CSP you provide it works fine for me with no CSP errors because there is a style-src-attr 'unsafe-inline'; which allows setting style="xxx" attributes. Changing this to style="none" and I am then able to reproduce some CSP errors. But There is some complexity here as now with this very strict policy we are being asked to block all style= attributes full stop and not allow them. So when i test full browser page loads here the csp correctly blocks all style attributes with csp warnings as you would want. Then when doing htmx boosted innerHTML swaps or back page history restores which also use innerHTML swaps it will first throw CSP errors trying to parse the content into a fragment with style attributes (but its not a live dom at this point so it blocks nothing and is just a warning). And then during pre swap it copies the old style from the current page for id'ed elts into the fragment by id and this throws a CSP and it blocks this set attribute leaving the fragment with the new style value. then it swaps it into the page and for some reason the browser does not enforce CSP here so the new style renders fine. Then settle action fires and it tries to copy a clone of the new style over the dom element but has the same style already so does nothing. Elements that are swapping in and removing or adding a style it seems to treat different and the CSP blocks stop it rendering the style tags here.

Testing in firefox it also worked fine with unsafe-inline with no CSP issues but when moving to 'none' it had different behavior and correctly blocked htmx applying all style tags.

So it seems htmx is able to partially work around the CSP protections browser have here sometimes. But I think if you want a very strict policy that blocks all style attributes then you should not return or allow any style attributes on the page and then it will not trigger any CSP issues. If you have a few style attributes you do need to use then hash them and add these hashes to your CSP. Also if you need a strict CSP then I recommend turning off includeIndicatorCSS config and if you need these request indicators CSS styles just create them in your own external .css file you manage.

Are you able to re-test with style-src-attr 'none' and style-src-attr 'unsafe-inline' and let me know what happens for your test project. maybe there is another factor we are missing here.