Earlier quoted context omitted.
I don't think this is being enforced in practice, thankfully.
It is. It happened to us a few weeks ago.
That's crazy. Did it happen to a public extension or an unlisted one?
Hardening the Firefox Front End with Content Security Policies
31–40 of 71 posts
Re: Hardening the Firefox Front End with Content Security Policies
#32Earlier quoted context omitted.
It is. It happened to us a few weeks ago.
That's crazy. Did it happen to a public extension or an unlisted one?
Public, with about half a million installations.
I think it was noticed only because this version had a major bug that broke a bunch of websites.
Re: Hardening the Firefox Front End with Content Security Policies
#33This 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 :(
Re: Hardening the Firefox Front End with Content Security Policies
#34This 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 :(
Xul would've had the same issues.
Re: Hardening the Firefox Front End with Content Security Policies
#35Earlier quoted context omitted.
Honest question: I don't understand how forbidding inline scripts and style improves security. Also it would be a serious inconvenience to the way we distribute some of our software right now lol
CSP tells the browser where scripts and styles can come from (not just inline, but origins/domains, too). Let's pretend that an attacker can inject something into a page directly (like a SQL injection, but HTML). That script can do just about anything, like steal data from any form on the page, like login, address, or payments, or substitute your elements for theirs. If inline resources are forbidden, the damage can…
Still recall the classic forum exploits of including Javascript in your signature or similar, before such software started escaping input.
Re: Hardening the Firefox Front End with Content Security Policies
#36CSP is really great at plugging these kinds of security holes, but it flummoxes me that most developers and designers don't take them seriously enough to implement properly (styles must only be set though , and JS likewise exists only in external files). Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.
> Doing any styling or scripting inline should be frowned upon as hard as table-based layouts. I strongly disagree: inlining your entire CSS and JS is absurdly good for performance, up to a surprisingly large size. If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it, I would recommend deploying…
I think that's a limitation of our implementations. In principle, it's just bytes that we shoving down the pipe to the browser, so it shouldn't matter for performance whether those bytes are 'inline' or in 'external resources'.
In principle, you could imagine the server packing all the external resources that the browser will definitely ask for together, and just sending them together with the original website. But I'm not sure how much re-engineering that would be.
Re: Hardening the Firefox Front End with Content Security Policies
#37Earlier quoted context omitted.
> Doing any styling or scripting inline should be frowned upon as hard as table-based layouts. I strongly disagree: inlining your entire CSS and JS is absurdly good for performance, up to a surprisingly large size. If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it, I would recommend deploying…
I think that's a limitation of our implementations. In principle, it's just bytes that we shoving down the pipe to the browser, so it shouldn't matter for performance whether those bytes are 'inline' or in 'external resources'. In principle, you could imagine the server packing all the external resources that the browser will definitely ask for together, and just sending them together with the original website. But I…
In principle there's no difference between principle and practice.
Re: Hardening the Firefox Front End with Content Security Policies
#38This 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 :(
Xul would've had the same issues.
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.
Re: Hardening the Firefox Front End with Content Security Policies
#39CSP is really great at plugging these kinds of security holes, but it flummoxes me that most developers and designers don't take them seriously enough to implement properly (styles must only be set though , and JS likewise exists only in external files). Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.
I find not being able to use inline styles extremely frustrating
Re: Hardening the Firefox Front End with Content Security Policies
#40CSP is really great at plugging these kinds of security holes, but it flummoxes me that most developers and designers don't take them seriously enough to implement properly (styles must only be set though , and JS likewise exists only in external files). Doing any styling or scripting inline should be frowned upon as hard as table-based layouts.
> Doing any styling or scripting inline should be frowned upon as hard as table-based layouts. I strongly disagree: inlining your entire CSS and JS is absurdly good for performance, up to a surprisingly large size. If you have less than 100KB of JS and CSS (which almost every content site should be able to, most trivially, and almost all should aim to), there’s simply no question about it, I would recommend deploying…
It's called Content Security Policy, not Content Performance Policy. My thoughts:
1. Inlining everything burns bandwidth, even if it's 100KB each. (I hope your cloud hosting bills are small.) External resources can be cached across multiple pageloads.
2. Best practice is to load CSS files as early as possible in the header, and load (and defer) all scripts at the end of the page. The browser can request the CSS before it finishes loading the page. If you're inlining scripts, you can't defer them.
3. If you're using HTTP/2+ (it's 2025, why aren't you?[0]), the connection stays open long enough for the browser to parse the DOM to request external resources, cutting down on RTT. If you have only one script and CSS, and they're both loaded from the same server as the HTML, the hit is small.
4. As allan_s mentioned, you can use nonce values, but those feel like a workaround to me, and the values should change on each page load.
> Local caches can be bafflingly slow, and letting the browser just execute it all in one go without even needing to look for a file has huge benefits.
Source? I'd really like to know how and when slow caches can happen, and possibly how to prevent them.
[0] Use something like nginx, HAProxy, or Cloudflare in front of your server if needed.