3 ms·
Yes. The issue is caused by the browser add-on. Before they get it fixed, I think it's better to notify HN users who use it. They said in previous posts that t
by simonmysun 2y ago
Yes. The issue is caused by the browser add-on. Before they get it fixed, I think it's better to notify HN users who use it.
They said in previous posts that they are using `DOMPurify` to sanitize the code, but it turns out that it did not work well.
- moritzwarhier 2y agoSo I'm not informed about this particular case, but DOMPurify does work correctly AFAIK. It's an old project though and I've always refrained from using it in favor of sanitizing user input in other ways (or letting library code do it for me). It might be that they used this library wrong. It might also be that it's more of a research project. There's a reason I guess that none of the popular UI frameworks/libraries have DOMPurify as a dep. It boils down to a separation similar to prepared statements. Disallowing direct string interpolation into DOM subtrees is the way to go, esp when user-controlled data is involved. You can't achieve XSS by assigning .textContent on a DOM node, for example. That's why the DOM API is a thing and innerHTML is equivalent to eval regarding security.
- simonmysun 2y agoI might have indicated it's DOMPurify's problem. Sorry I didn't mean that. The browser add-on is unfortunately not open source and I don't want to spend a lot of time to investigate it. According an earlier issue (#1437), they should have fixed it already. I guess the later envolvements changed that. I agree with you that what DOMPurify does should be cared of by the Browser.