HN user

latent22

30 karma
Posts0
Comments9
View on HN
No posts found.

there is a Additional HTMX configuration section and it is interesting that all 4 issues here have now been resolved by default in htmx4. History cache is now not included by default and you have to opt in to the new improved history extension. Attribute inheritance is now off by default and has a much better implicit inherit design. Indicator styles are no longer a manual injected style tag and now use constructable style sheets feature which is much cleaner and CSP safe. and default timeout is no 60s.

These are all existing common pain points that the new version allows us to address.

then you may be able to do things like this I think

  <mesh-card id="card-123" hx-swap-oob="true">
    <template shadowrootmode="open">
      <link rel="stylesheet" href="/static/css/components/card.css" />
      <div class="card">
        <div class="card-header">
          <h3>Updated Card Title</h3>
        </div>
        <div class="card-content">
          Updated card description here.
        </div>
        <div class="actions">
          <button type="button">Edit</button>
        </div>
      </div>
    </template>
  </mesh-card>

  class MeshCard extends HTMLElement {
    connectedCallback() {
      if (!this.shadowRoot) {
        const tmpl = this.querySelector('template[shadowrootmode="open"]');
        if (tmpl) {
          this.attachShadow({mode: 'open'})
            .appendChild(tmpl.content.cloneNode(true));
        }
      }
    }
  }

  customElements.define('mesh-card', MeshCard);

Hey alex-moon one feature you had issues was that HTMX does not process server generated shadow DOM content because it uses the standard old DOM parser. Next point release should have https://github.com/bigskysoftware/htmx/pull/3185 merged hopefully which will allow the use of Document.parseHTMLUnsafe() which is the modern browser replacement that does support this use case but it might go behind a new config flag.

The bug in 2.0.3 just breaks one default use case and where you pass in no source or target to the api so anyone using this feature their app broke on upgrade to 2.0.3 and they had to set a source explicitly or revert the version. 2.0.4 just fixes this with no downside unless you like seeing console errors

Actually this was just a stupid bug I introduced in 2.0.3 which was found soon after 2.0.3 shipped. I fixed a bug that allowed ajax api to target body and blow away your whole page in error if one of the selectors you pass in was not found. But It broke the default no source and target behavior but this is now fixed that 2.0.4 is shipped

https://github.com/MichaelWest22/htmx-extensions/tree/main/s...

one great feature of htmx is how easy it is to understand and develop extensions for. I've just implemented this extension which allows safer handling of CSP nonce if this was required by an application. Hopefully this will get accepted as an official htmx extension.

My advice is if your not using inline script tags or the eval feature just keep it simple and disable allowScriptTags and allowEval and set a good CSP header. Also make sure you set a htmx-config meta tag in your page headers to set your config and protect from injected meta tags.

If you need inline scripts in a few places then be aware you need to choose a good templating or auto escaping engine on the backend to protect you and think about user inputs and be careful when using any raw escape override functions. If you have a sensitive application that needs regular external pen-testing then look at things like my safe-nonce extension that gives you another layer of protection to sell.

Yeah the risk here is very low unless they start hosting more complicated content later on. But it is not hosted on S3 and is actually hosted by AWS CloudFront with a S3 origin which now has a built in feature to set security headers for your static site in only a few clicks so you can get that sweet sweet A rating ;)

Lets dig in:

Loading malicious fragments: This is in no way related to htmx and is the same for all web implementations because you don't go get possible script code from random untrusted domains you don't trust or control. Also if he had tried this with the current version of htmx (2.0) he would have not been able to do this as it now defaults to blocking hx requests to external sites and you can only use local relative paths now. So win to htmx on this point.

Unsafe eval: Yeah unsafe eval looks bad but almost every other client side framework also has this same issue and it is very hard to turn this one off on any modern interactive or SPA like website today. Htmx has the option to just ignore the two features that need unsafe eval and implement these features with other more custom solutions unlike most other solutions so I have to chalk this up as a second win for htmx.

Disabling HTMX with hx-disable: I think it fair that hx-disable is not a fool proof security feature and is there to stop silly things and provide some isolation for content to separate it from htmx. But you should probably not allow un-sanitized data in here and expect this to save you.

Nonces for inline scripts: Yeah htmx has some support for nonces and they can protect from inline scripts inserted into the page somehow but they won't protect you from scripts returned from your trusted local server via hx requests by design. Another small win here.

Configuration meta tag: This one is a fair point and the use of malicious meta tags is an interesting attack vector. This may weaken some of the security features built into htmx but if you allow un-sanitized user input to be returned by your server like in his example app there are not many solutions that will come off any better off.

Conclusion: When a site uses HTMX, the attack surface of HTML injection is the same as any other SSR solution. It is possible to limit the risk of XSS by using a content security policy. Security is simple and old school as you just sanitize your inputs which all modern backend stacks now make easy. But it not possible to have all HTMX features and provide 100% security against injection (unless you sanitize all inputs and only link to your own server).