Safe-nonce extension

[MichaelWest22]

Here is a new extension that improves the security of the inlineScriptNonce feature built into htmx. Htmx by default implicitly trusts the server to return safe sanitized data from all requests and if you use the inlineScriptNonce feature it will auto apply the correct nonce to satisfy your CSP policy so you don't need unsafe-inline set. This does open the door for possible XSS issues though if you don't auto-escape or use templating engines to prevent problematic user input. While this does not replace the need to ensure you escape all user input by improving this gap in htmx nonce handling you can add another layer of defense to your website.

The secret to making this extension work is the new HX-Nonce response header it adds that allows you to supply this during a htmx partial AJAX response and it will only resolve the script tag nonce attributes for the script tags that match your random nonce supplied in your header. An attacker who wanted to inject inline scripts would have to control the server response header and not just an un-escaped section of the page contents. This design matches what would be required if htmx style ajax partial page requests was ever built into native browser support where the browser would have to check and process nonce data in the CSP headers of partial responses and adjust them to match the main page load nonce.

[netlify]

✅ Deploy Preview for htmx-extensions canceled.

Name	Link
🔨 Latest commit	1417788
🔍 Latest deploy log	https://app.netlify.com/sites/htmx-extensions/deploys/669880614856ce00081726ca

[Telroshan]

Hey, sorry for the delay. After giving this more thought, I would suggest publishing your own extension repo for now and list it in this repo's community extensions.
Adding an extension to the repo itself makes it kind of an "official" extension that we'd have to provide long-term support for, I hope you'll understand we can't do that with all extensions!
All extensions in this repo were already there in 1.0, and with htmx 2 we wanted to take a different approach, to let community easily register their extensions in our extensions list while we let them handle their support.

We can always discuss later if an extension should or should not make it into the core, but I would suggest making it a community extension first.

I know this can feel frustrating, apologies for that! We'll have to define contributing guidelines at some point for this repo, we're still playing it by ear for now

[MichaelWest22]

Thanks @Telroshan. Yeah the core vs community thing was kind of confusing. I've already prepared the extension in my own cloned repo so I can link that in that way for now. In my view having a safe recommended way to handle security concerns is kind of core so would be good to get in and properly maintained at some point but have to prove it works and is really needed first! Still trying to work out how to protect hx-on tags from injection attacks with an extension but that is proving a bit more complex