Hacker News Reader

Comment by Abishek_Muthian | Hacker News Reader

I'm bit sad that hyperscript[1] doesn't get the love it deserves when discussing HTMX.

Hyperscript fits perfectly in the Go + HTMX stack to do DOM manipulation without having to make a server round trip or having to write a separate JS function.

I get that not many are fan of such declarative programming, but when there's already HTML file we're working with; Hyperscript feels just like an extension of it.

I have been working on a Open Payment Host[2] which handles multiple payment gateways and was able to perform complex DOM manipulation with just Hyperscript.

[1] https://hyperscript.org/

[2] https://openpaymenthost.com/

View on HN

There's security consequences to allowing inline JS, which hyperscript requires.

How so? Final validation always goes in the server side.

It means that you have to use a less strict Content-Security-Policy, which increases your vulnerability to various client-side JS attacks.

Actually even with a strict CSP i.e. without unsafe-inline, hyperscript will work as it's declared as html attributes. But as the other commenters have pointed out, with proper server validation in place the risk from Hyperscript is not greater than any other JavaScript in the application.

Will it not need unsafe-eval, though? It still creates the potential for HTML injection to lead to execution of untrusted code. Execution of untrusted code is the real issue, regardless of exactly how that code ends up being evaluated and executed. Even if Hyperscript were to have its own interpreter (so that it didn't even need unsafe-eval), you'd still have the same fundamental vulnerability (unless you add nonces, or some such).

>the risk from Hyperscript is not greater than any other JavaScript in the application.

This is not really the case. If all of your client-side code is loaded via <script src="..."> tags from bundles on your server, and you have a CSP that blocks unsafe-eval or unsafe-inline, then you have a pretty good barrier against execution of untrusted code on your page.

AFAIK Hyperscript doesn't require `unsafe-eval`, when the optional features of htmx like `hx-on:*`, `hx-vals js:`, `hx-confirm js:` is used it required the `unsafe-eval` but now there's extension[1] to use even that without compromising on strict CSP through nonce.

[1] https://four.htmx.org/extensions/hx-csp

That’s interesting, thanks. I agree that with all those extra protections enabled, there is no security issue.

The same server that's responsible for sanitizing garbage JS out of user content is also responsible for sending the Content-Security headers. Why would you trust it with one, but not the other? If it's buggy garbage it will also send the wrong headers.

This is a pretty good argument in the case of software written by a small team of experienced engineers. In that scenario, if the engineers don't have the nous to avoid the kinds of HTML injection vulnerabilities that might allow an attacker to inject their own JS code, then, as you say, they are probably also making lots of other mistakes.

A CSP is more valuable in a larger organization, where the codebase is always at risk of being modified by the organization's worst engineer.

Reply on news.ycombinator.com