News for hackers. Stuff that matters.

A comment on Hardening the Firefox Front End with Content Security Policies.

Re:Hardening the Firefox Front End with Content Security Pol... by lol768 on Wednesday April 09, 2025 @08:59AM (#43631552)
This is an entire class of vulnerabilities that would've never been possible with XUL, is that correct?

I appreciate they had to move for other reasons but I also really don't like the idea that the DevTools and browser chrome itself now has all of the same security issues/considerations as anything else "web" does. It was bad with Electron (XSS suddenly becoming an RCE) and makes me pretty nervous here too :(

[ Parent | on HN ]
Re:Hardening the Firefox Front End with Content Security Pol... by emiliocobos on Wednesday April 09, 2025 @09:12AM (#43631677)
Xul would've had the same issues.
[ Parent | on HN ]
Re:Hardening the Firefox Front End with Content Security Pol... by sebazzz on Wednesday April 09, 2025 @12:14PM (#43633749)
It still surprises me parts of Firefox still use XUL.
[ Parent | on HN ]
Re:Hardening the Firefox Front End with Content Security Pol... by WorldMaker on Wednesday April 09, 2025 @10:03AM (#43632263)
XUL would have had worse issues because it could make arbitrary XPCOM calls to all sorts of native components and nearly the full gamut of native component issues written mostly in C/C++.

XUL was in many ways always a ticking time bomb.

[ Parent | on HN ]
Re:Hardening the Firefox Front End with Content Security Pol... by fabrice_d on Wednesday April 09, 2025 @07:33PM (#43639122)
The current frontend still has the same XPCOM privilege access from JS, so as emiliocobos said, XUL vs. HTML does not change the security boundary. It's only a different markup language.
[ Parent | on HN ]