Hacker News Reader

Comment by germandiago | Hacker News Reader

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.

Reply on news.ycombinator.com