Hacker News Reader

Comment by hellcow | Hacker News Reader

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

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.

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