Discussion: appetite for an opt-in helper to neutralize dangerous URL schemes in `Href`?

[yamaga-shu]

Hi, and thanks for gomponents — the 1:1-with-HTML, minimal-by-design approach is exactly why I like it.

I'd like to gauge your appetite for a small addition before putting any work into a PR.

Context

gomponents HTML-escapes attribute values, which is great, but it doesn't inspect the scheme of a URL in Href. I assume that's intentional and consistent with the library's philosophy. The consequence is that a value from user or external input can still produce a dangerous link:

A(Href(userInput), Text("click"))
// userInput == "javascript:alert(1)"  -> clickable XSS

Escaping doesn't help here, since it doesn't change the navigation target.

What I'm not proposing

No change to the default behavior of Href. This is only about an opt-in helper.

What I'd like your opinion on

Would you be open to an opt-in helper that users explicitly choose, leaving Href untouched — something narrow that neutralizes dangerous schemes (collapsing them to "#") and passes everything else through unchanged? For example a SafeURL(string) string sanitizer, and/or a SafeHref(...) attribute built on top of it.

I realize the core library is intentionally feature-complete, so I'm not assuming this belongs in html. If a core addition isn't a fit, would something under x/ (alongside x/slices) be more in line with how you'd want to handle this? And if you'd rather keep URL handling entirely in user code, that's a completely reasonable answer too — I'll just keep it in my own project. I only wanted to check before writing anything. Happy to send a PR with tests if there's interest.

Thanks!

[markuswustenberg]

Hey @yamaga-shu , thank you for your issue!

I'm certainly not against the idea (in a separate package, as you propose), but it depends on whether it's possible to create something that's broad and generic enough, while still adding value. I have very little experience with making URLs safe, for whatever definition of safe.

I'm sure some projects have a ton of experience with this, so we wouldn't have to start from scratch. Something like bluemonday. Maybe it's easier to make an easy integration with something like that?

What's your experience?

[yamaga-shu]

@markuswustenberg

Thanks for the reply, and for being open to a separate package. I dug into it, and I think the scope can be cleaner than I first proposed.

On bluemonday

It solves a problem one level up — full HTML-document sanitization (parse the tree, apply an allowlist, return HTML) — whereas this is just about the scheme of a single string in Href. Worth a docs pointer for full UGC sanitization, but it's the wrong primary mechanism here.

The better reference: the stdlib

html/template doesn't just escape URL values — it filters the scheme. urlFilter (via isSafeURL) allows only http, https, mailto (plus relative URLs) and defangs everything else to #ZgotmplZ.

Because gomponents renders nodes directly and deliberately skips html/template, it sits outside exactly this safety net. So the proposal isn't "let's invent a definition of safe" — it's "optionally restore the scheme guarantee the stdlib already defines," using its behavior as the spec. That also answers your concern: neither of us has to define safe; the Go team already did, conservatively and with a documented rationale.

One nuance: both functions are unexported, so today there's no way to reach that check from the direct-render path short of re-copying the rule into user code.

Proposed shape

A single tiny, dependency-free helper under x/ mirroring that rule — named after the stdlib's own urlFilter rather than promising "safe", since the behavior is a scheme filter, not a sanitizer:

FilterURL(string) string   // relative + http/https/mailto pass through; everything else → "#"

Used at the call site, it stays explicit and opt-in, with no change to Href:

A(Href(x.FilterURL(userInput)), Text("click"))

The core stays minimal — this just lives alongside the other x/ convenience pieces. (Happy to bikeshed the name; I just leaned on the stdlib's vocabulary for consistency.)

On faithfulness: I'd mirror isSafeURL exactly, including its relative-URL handling (strings.Cut(s, ":") → treat as relative when the part before the first colon contains a /), with table tests covering the relative/scheme-defang edge cases — pinned to the stdlib's behavior rather than eyeballed.

One thing to flag: the stdlib allowlist is strict — tel: isn't on it (debated in golang/go#20586). I'd just mirror the stdlib's set as-is, so the helper's behavior stays a faithful copy of a documented spec rather than a judgment call of mine.

---

If that sounds reasonable I'm happy to open a PR with tests. And if you'd rather keep URL handling in user code, that's fair too.

[markuswustenberg]

@yamaga-shu could you reply in your own words? It feels like I’m talking to a bot. I much prefer broken but human English to a Claude Code post. :-)

[yamaga-shu]

@markuswustenberg
Sorry about that! This is my first time opening an issue on an OSS project in English, so I got a bit too stiff.

What I want is simple. I'd love to add a small helper in x/ that does the same scheme check as urlFilter in Go's standard library. The stdlib one is unexported so you can't call it directly — so the idea is a thin function that copies the same rule.

userInput := "javascript:alert(secret)"

A(Href(x.FilterURL(userInput)), Text("click"))
// -> <a href="#">click</a>

It only collapses dangerous ones like javascript: to #, and lets everything else through.

[markuswustenberg]

No worries. :-)

I've thought about this, and I've decided I'd rather document how to achieve something like this using something outside gomponents. I don't want to be responsible for maintaining something that is definitely not HTML, which is the scope of the project. So the task now is to research some modules to achieve this, and document it somewhere in the repo, perhaps as an example.

[kwiat1990]

I'm with @markuswustenberg on this one. It would be nice and handy to have it build-in but also it would exceed the limit of what's allowed. The same goes for the values of any other attribute on HTML tags: you can pass anything into them without any kind of validation, just like while using plain HTML. Otherwise one could expect that the attribute's value is also validated or typed, which is not the case for gomponents. For that you could check up fluent, which is somehow based to gomponents but yet different.