Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to migrate NodeValidatorBuilder #250

Closed
Carapacik opened this issue Jun 2, 2024 · 5 comments
Closed

How to migrate NodeValidatorBuilder #250

Carapacik opened this issue Jun 2, 2024 · 5 comments

Comments

@Carapacik
Copy link

How to migrate NodeValidatorBuilder from dart:html to web?
And how to setInnerHtml with validator on web for HTMLHtmlElement?

@kevmoo
Copy link
Member

kevmoo commented Jun 2, 2024

Great question! @srujzs @sigmundch – have we hit this in other migrations?

@srujzs
Copy link
Contributor

srujzs commented Jun 3, 2024

We haven't hit this yet afaik. We could move this functionality into the helpers, but I believe our long-term goal is that we don't own validation/sanitization as it poses a security risk, and would rather have users use a combination of package:safe_html (which is unfortunately internal only), conformance checks (which is also internal only), and safer browser APIs (like trusted types). Thoughts?

For this specific case (setInnerHtml), the safer alternative seems to be Node.textContent: https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML#security_considerations. I suspect TrustedHTML is also a good alternative, but that won't work on Firefox.

@isoos
Copy link
Contributor

isoos commented Sep 21, 2024

I'd like to reopen this question.

I want to migrate package:domino to wasm-ready, and it previously supported arbitrary HTML content via setInnerHtml. Is there any fundamental blocker that prevents us the use of setting innerHtml? I get that there are security considerations, but I think a fundamental library like package:web shouldn't hide it unless it is an unsupported feature.

@sigmundch
Copy link
Member

To clarify: the browser API is already exposed today (see the Element.innerHTML setter), it just doesn't have the additional guardrails that dart:html's setInnerHtml method had from using the node validator. As such, uses of Element.innerHTML should be treated as unsafe and a potential source for XSS vulnerabilities.

There are safer alternatives we could build/expose, but we haven't yet. After years of experience with the dart:html APIs, we concluded that the node-validation-builder approach is not ideal. So rather than porting that over as a helper in this library, we would prefer to expose a variant like package:safe_html and/or rely more heavily on trusted types like TrustedHTML that were recently added to browsers.

@isoos
Copy link
Contributor

isoos commented Sep 23, 2024

@sigmundch: oh, cool, thanks for the clarification. It turns out for my case I need to use setHTMLUnsafe...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants