Open Bug 1039678 Opened 10 years ago Updated 1 year ago

Add the equivalent of Google Chrome --disable-web-security to Firefox developer options to globally disable CORS security features.

Categories

(DevTools :: General, enhancement, P2)

Product:
DevTools
Component:
General
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: jujjyl, Unassigned)

References

(Blocks 1 open bug)

Details

(4 keywords, Whiteboard: [gaming-tools])

Attachments

(1 obsolete file)

Firefox should add an about:config pref so that developers can make the browser disable all CORS policy checks, identical to how Chrome --disable-web-security startup option functions. Searching through the different discussions around this, I understand that this is a potentially controversial topic, but this really needs to be implemented, because: 1) Chrome, Safari, Internet Explorer and Opera all support developer options that disable CORS security checks already. 2) Thousands of developers are asking about this feature. 3) Having to install third-party developed browser add-ons or to implement proxies are not workarounds because they feel fishy, or require a high learning curve to set up. Fixing up the misconfigured server that is sending wrong headers is not always an option, so developers do often need workarounds. For Firefox developers, the workaround currently is "please use any other browser than Firefox", which flags Firefox as a developer-unfriendly browser. Instead of taking an elitist stance, we should implement the same developer options to easily work around this issue.
This seems like a terrible idea to me.
A comment like above fails to understand important and efficient development processes and practices that companies employ. One-man shops and elite do-it-all-yourself programmers falsely assume that every person, just like they themselves are, would be in control of everything and be knowledgeable about everything involved in the development of that software system. Not providing an easy workaround prevents efficient multitasking and meaningful workflow management along the lines of "Let's send an email to the server team to fix this, and ignore this for now and move on." or "I don't know what is going on here, I'll ask Chris tomorrow, but I really need to finish my task in the meanwhile." or "I don't have access to this server and the server guy is on vacation." or "Uh, CORS? <5 min googling> Oh, some server thing - not my problem, I don't touch the server, ignore." Anyone saying "you don't." or "terrible idea" about how to disable CORS does not understand that the problem has nothing to do with CORS. Metaphorically it is about not shutting the other processes of the OS down when one process crashes; it is about not showing modal popups in UIs for no reason when anything else would be more important to access instead; it is about maximizing core utilization and parallel threading throughput; and it is about being able to run the remaining tests in the suite even after the first one of them fails. Developers will need to develop and need to be able to have workarounds when they face errors they cannot resolve themselves. This fault tolerance.
Adding Jeff from devtools to find the right contact for the pref in devtools (maybe in the Network panel?) and Dougt for input from the networking side.
Flags: needinfo?(jgriffiths)
Flags: needinfo?(dougt)
ni?ing Mark, who is our devtools security person.
Flags: needinfo?(mgoodwin)
Dangerous footgun! I could support this if it was only in Nightly and Aurora -- and it was only a command line, not a preference. Patches accepted.
Flags: needinfo?(dougt)
Firefox OS phones suffer from the same limitation, so a command line option is not feasible there. If this was a pref, it would equally work in both contexts.
I would rather resolve bug 939201 and provide some upfront tooling support for CORS issues, rather than an all-or-nothing pref that is neither discoverable, nor does it help developers deal with CORS trouble-shooting. But, we haven't gotten around to fixing that bug and everyone else does it, so it might be a 'quick fix' that helps some people right away.
Flags: needinfo?(jgriffiths)
(In reply to Nick Fitzgerald [:fitzgen] from comment #4) > ni?ing Mark, who is our devtools security person. This is dangerous but I can see why it'd sometimes be useful to do it. There are equivalently dangerous things you can already do without resorting to command line but I'm with Jeff in comment #7 here; I think the right thing to do is to add upfront tooling that allows you to do this a) selectively, and b) temporarily.
Flags: needinfo?(mgoodwin)
(In reply to Doug Turner (:dougt) from comment #5) > Dangerous footgun! I could support this if it was only in Nightly and > Aurora -- and it was only a command line, not a preference. The problem with that is that is changes the behaviour of the browser - I would rather we create a feature that does not change the behaviour, but instead provides much better insight into the existing behaviour. Having a command-line flag in Nightly & Aurora doesn't really help developers because their stuff has to eventually work in Beta.
(In reply to Jeff Griffiths (:canuckistani) from comment #9) > (In reply to Doug Turner (:dougt) from comment #5) > > Dangerous footgun! I could support this if it was only in Nightly and > > Aurora -- and it was only a command line, not a preference. > > The problem with that is that is changes the behaviour of the browser - I > would rather we create a feature that does not change the behaviour, but > instead provides much better insight into the existing behaviour. > > Having a command-line flag in Nightly & Aurora doesn't really help > developers because their stuff has to eventually work in Beta. ...and most importantly, have some indication in the tools of CORS issues when they happen - currently it's very difficult to see anything going.
(In reply to Jeff Griffiths (:canuckistani) from comment #9) > The problem with that is that is changes the behaviour of the browser - I > would rather we create a feature that does not change the behaviour, but > instead provides much better insight into the existing behaviour. Naturally having better prints is always helpful, but that alone doesn't solve this, since sometimes you don't have login to the server you are developing against, or the server guys are in different timezone and it's night there, or it's someone else's job and you are not allowed to change the server code anyways. For all these things, the current best thing one can do is to stop using Firefox and run chrome --disable-web-security. I understand the rationale for not offering an option has been to force people to fix their servers, but that is a bit naive to try to force people to one serial workflow, and instead it just amounts to an internal memo "everyone else than server team, take a vacation until the problem is fixed" or "please use any other browser than Firefox until the problem is fixed". No tool should force serial workflow for anything whenever possible. Note that we are equally as much interested in having the same workaround ability Firefox OS, since when this issue occurred, we were developing and testing Firefox OS packaged app deployment as well.
Whiteboard: [IE-parity][Chrome-parity][opera-parity]
(In reply to Jukka Jylänki from comment #11) ... > Naturally having better prints is always helpful, but that alone doesn't > solve this, since sometimes you don't have login to the server you are > developing against, or the server guys are in different timezone and it's > night there, or it's someone else's job and you are not allowed to change > the server code anyways. For all these things, the current best thing one > can do is to stop using Firefox and run chrome --disable-web-security. That's an awesome articulation of the use case - thanks. I'm definitely more amenable to this change now, especially if we keep it out of Release / Beta.
Thanks Jeff. I think if we require the developers install Aurora or Nightly, this will add an extra step that developers need to start installing new software, which sounds very bad ("please adjust your system installation if you want to work around this, and install completely another _version_ of the product."). Also, that would not allow the workaround for Firefox OS without flashing a custom build, which would be catastrophic. Also, that might lead to issues where developers hop from one issue to another and stories of form "in stable, I can't work around CORS, but if I install Nightly, I get around CORS but then get this other crash/bug now", since Aurora and Nightly are development branches and often contain other bugs. I would recommend just doing the simplest thing that gives the most convenient developer experience and have a pref that allows working around this. Chrome shows a nice startup banner/popup at each time you start up with such an option enabled, which keeps reminding the developer that he's now running with low-security options, but the banner doesn't get in the way and is easy to close. I think they did everything right here for this option. If we're worried that developers forget the option on, then let's do something similar, show a banner, replace the Firefox logo with a Jolly Roger flag, repaint the window borders with Nyan Cat animations throughout the session or whatever else we feel necessary to remind that the developer is now running with low security.
I'm also against requiring Aurora/Nightly. That would mean that people can do security testing OR they can make tests on the browser that their users are using but not both. Launching Firefox from the command line with --disable-web-security is non something that people-at-risk are going to do by mistake, or even easily, and if I have the ability to coerce someone into typing random stuff at the command line, I'm not going to start with --disable-web-security.
Any word on when this might be addressed? I just had to switch to Chrome to work on a project under the scenario described by Jukka.
(In reply to dbuc from comment #15) > Any word on when this might be addressed? I just had to switch to Chrome to > work on a project under the scenario described by Jukka. It's not planned, meaning there is no current schedule that includes it (please see https://wiki.mozilla.org/DevTools/Planning/Status for insight on how we're using whiteboards to track things)
Whiteboard: [IE-parity][Chrome-parity][opera-parity] → [parity-ie][parity-chrome][parity-opera]
Severity: blocker → normal
Attached patch 0001-disable-CORS.patch (obsolete) (deleted) — — Splinter Review
This seems to disable CORS checking by Firefox.
wow, and hence i had to move to chrome. I was expecting atleast Firefox developer edition to allow this. The patch above ^, how do I use that, is that in the latest firefox developer build?
(In reply to sp from comment #24) > wow, and hence i had to move to chrome. I was expecting atleast Firefox > developer edition to allow this. > The patch above ^, how do I use that, is that in the latest firefox > developer build? In order to use that patch, you would need to apply it to a checkout of mozilla-central and then create your own build.
(In reply to sp from comment #24) > wow, and hence i had to move to chrome. I was expecting atleast Firefox > developer edition to allow this. > The patch above ^, how do I use that, is that in the latest firefox > developer build? As Jeff Griffiths mentioned, you would have to checkout the mozilla source code, apply that patch and rebuild firefox from the patched source.
(In reply to Joe from comment #26) > (In reply to sp from comment #24) > > wow, and hence i had to move to chrome. I was expecting atleast Firefox > > developer edition to allow this. > > The patch above ^, how do I use that, is that in the latest firefox > > developer build? > > As Jeff Griffiths mentioned, you would have to checkout the mozilla source > code, apply that patch and rebuild firefox from the patched source. Too much work. I would just continue to use chrome and canary till then sadly. I liked the Firefox developer edition.
The lack of these feature is wasting my time. How about letting developers do what they want instead of treating them like children?
Comment on attachment 8627429 [details] [diff] [review] 0001-disable-CORS.patch A customer of mine just came along and insisted that I apply the patch in this bug to their browser, which they ship to end users. To work around some random issue with one big website not working in their specific situation. dougt and other core Mozilla devs have already said "dangerous" here, but clearly that isn't enough for some people to understand. So, I want to warn everybody here: Applying this patch is disastrous for your security. It's called "disable web security" for a reason. For one thing, it completely gets rid of any cookie protections, so that website A can steal cookies for website B, which means that any website you visit (or any JS advertizement on a news website you visit) can steal your account from any other website. Bye bye Google account, bank account info, company internal sites, or whatever else you have, if you're out of luck. So, Jeff and others are completely right in asking for more specific developer tooling in debugging and modifying CORS headers. I know there hasn't been any progress. If you're frustrated about the status quo, you can help out, the Firefox dev tools are built in JS. I recommend WONTFIX for this specific request, in favor of
Attachment #8627429 - Attachment is obsolete: true
Attachment #8627429 - Flags: review-
... in favor of bug 1121824
@BenB, this is both crazy story and crazy reasoning :) let's not ban knives because you cut yourself once, k?
So, I think all developers understand the risks here. You can even have a popup if browser is present in this disabled web security mode. But, as a developer I would like the freedom to use it. I am not even speaking about adding it to main build, I am requesting it to be added(not the patch if it doesnt do that, the feature) to Firefox Developer Edition. Obviously, no one would be downloading that version of browser unless they are developers. Then, they have to start the browser in a special mode. The browser gives a popup to warn. Even after all this, if I as a developer wants that feature for some particular reason, I just dont understand why I cant have it. I love Mozilla and Firefox and developer edition, just dont want to stop using it because people think all developers are not aware of what are the risks resulting in this feature not added to it.
Everybody, I've just found that there is an addon that takes the problem out of firefox developers hands and solves it, https://github.com/spenibus/cors-everywhere-firefox-addon Did not try it yet, but - as long as it works - this feature request can be shelved.
(In reply to Makc from comment #33) > Everybody, I've just found that there is an addon that takes the problem out > of firefox developers hands and solves it, > https://github.com/spenibus/cors-everywhere-firefox-addon > > Did not try it yet, but - as long as it works - this feature request can be > shelved. Tried that addon. It did not help for my usage. I use a website that relies on using CORS and does not work well without it. I have a firefox build with this patch just to browse that particular website. For all other browsing, I use the default firefox build of my distro.
I think our approach isn't wanting to ban knives because you can cut yourself. We'd like to find something more fine-grained that solves the problem without the dangerous downsides. I guess we'd like to not build nukes because we'd like to build knives instead. Now maybe there isn't a good way to define a sufficiently sharp knife, and this ends up being more nuclear. But I have hopes of a knife option.
@jwalker this thread started from mentioning chrome. they have it done quite safe, imho, - not as permanent option but one-time command line argument. close the browser, and the next time it runs you're back to safety.
(In reply to Joe Walker [:jwalker] (needinfo me or ping on irc) from comment #35) Joe, the reality here is that devs aren't going to flick this on and leave it running while they do their banking and sharing of cat pics to Facebook - this is a very development-centric need that would never be run outside specific use-cases. To ensure it isn't left on accidentally, you could have it be an option in the dev tools control panel that ties the setting to a tab or domain, then always wipe the setting when the tab is closed (if this is feasible). Something like that would probably mitigate any realistic concerns about pwnage of the user's data.
From reading previous comments, I think we're fairly convinced that adding similar command line option is a reasonable thing. So, we just need to prioritize this work against all the other things to do.
Ryan mentioned confusion as to what I was saying in comment 35, so I'll be clearer: If we could have a system where we have a pref that enumerates origins against which we will disable security then it's possible that we could have a system that is both easier to use than Chrome's solution, but also safer for the cases when developers 'just check some docs quickly' using their test browser. Now 'enumerating origins' is probably easier to say than do - the devil is likely to be in the details there. If there isn't an 'enumerating origins' solution or if it's so difficult that the command line option is better then lets do the command line thing, but I think we should consider some sort of 'enumerating origins' properly first.
Flags: needinfo?(mgoodwin)
This is another feature that could make use of a potential "developer project" concept: Part of having an active "developer project" could be the set of expected origins for that project. Then, we could use that info to relax security for those origins if desired.
(In reply to Joe Walker [:jwalker] (needinfo me or ping on irc) from comment #39) > Now 'enumerating origins' is probably easier to say than do - the devil is > likely to be in the details there. You should be able to do this; something similar to the aforementioned add-on ought to work fine... but with the difference that you only add the response header in cases where the request's origin is in some whitelist (contained in the pref). It'd be nice to do something to stop "set and forget" - maybe clear after some time or on new sessions?
Flags: needinfo?(mgoodwin)
Thanks Mark, So I have a list of origins in my prefs labelled "No security for these origins". There is an issue that's just occurred to me - how is this activated? In my head it's permanent or at least easy to turn on, making "set and forget" more of an issue. Does that change your thinking on this? There's a worry that an add-on or something else system level would be able to do something akin to "set no-security-origins = [*]" as a way to disable a users protection. I assume this isn't a concern for you because there are lower hanging fruit, like stealing the cookie jar, right?
Flags: needinfo?(mgoodwin)
(In reply to Joe Walker [:jwalker] (needinfo me or ping on irc) from comment #42) > Thanks Mark, > > So I have a list of origins in my prefs labelled "No security for these > origins". There is an issue that's just occurred to me - how is this > activated? In my head it's permanent or at least easy to turn on, making > "set and forget" more of an issue. Does that change your thinking on this? I don't have an issue with this being easy to turn on. To my mind, making this permanent is more problematic. Could we add a nag to the webconsole for responses that are modified in this way? > There's a worry that an add-on or something else system level would be able > to do something akin to "set no-security-origins = [*]" as a way to disable > a users protection. I assume this isn't a concern for you because there are > lower hanging fruit, like stealing the cookie jar, right? I wouldn't be too worried about the add-on scenario - since an add-on can do something equivalent (or worse) in any case.
Flags: needinfo?(mgoodwin)
OK, so the alternative to the command line flag is: We have a place in the UI to configure a set of origins for which security is turned off. This set of origins can contain simple wildcards (like '*' rather than full regexps). Setting origins using IP address is allowed. Security will be disabled for any request to an origin when the following requirements are met: 1. Devtools are open 2. The 'disable security' switch is on (and visible) 3. The request origin matches an origin configured for no security If devtools are closed when the switch is on, then we revert to security being enabled everywhere. The switch can not be hidden while it is enabled. The switch will have some red danger marker so you know there's something up. --- I think this is safer than a command line switch because it can't be forgotten and has a narrower scope. I think that once configured, it's easier to use because you don't need to restart the browser. I also think the requirement to have devtools open is extra protection against misuse by addons. Anyone disagree?
(In reply to Joe Walker [:jwalker] (needinfo me or ping on irc) from comment #44) > OK, so the alternative to the command line flag is: > > We have a place in the UI to configure a set of origins for which security > is turned off. This set of origins can contain simple wildcards (like '*' > rather than full regexps). Setting origins using IP address is allowed. > > Security will be disabled for any request to an origin when the following > requirements are met: > 1. Devtools are open > 2. The 'disable security' switch is on (and visible) > 3. The request origin matches an origin configured for no security > > If devtools are closed when the switch is on, then we revert to security > being enabled everywhere. The switch can not be hidden while it is enabled. > > The switch will have some red danger marker so you know there's something up. > > --- > > I think this is safer than a command line switch because it can't be > forgotten and has a narrower scope. I think that once configured, it's > easier to use because you don't need to restart the browser. I also think > the requirement to have devtools open is extra protection against misuse by > addons. > > Anyone disagree? this is awesome imho
(In reply to Joe Walker [:jwalker] (needinfo me or ping on irc) from comment #44) > OK, so the alternative to the command line flag is: > > We have a place in the UI to configure a set of origins for which security > is turned off. This set of origins can contain simple wildcards (like '*' > rather than full regexps). Setting origins using IP address is allowed. > > Security will be disabled for any request to an origin when the following > requirements are met: > 1. Devtools are open > 2. The 'disable security' switch is on (and visible) > 3. The request origin matches an origin configured for no security > > If devtools are closed when the switch is on, then we revert to security > being enabled everywhere. The switch can not be hidden while it is enabled. > > The switch will have some red danger marker so you know there's something up. > > --- > > I think this is safer than a command line switch because it can't be > forgotten and has a narrower scope. I think that once configured, it's > easier to use because you don't need to restart the browser. I also think > the requirement to have devtools open is extra protection against misuse by > addons. > > Anyone disagree? How does one enable it for a Firefox OS device?
(In reply to Jukka Jylänki from comment #46) > How does one enable it for a Firefox OS device? Through devtools / prefs. Another good reason for not doing a command line switch.
(In reply to Jukka Jylänki from comment #46) > (In reply to Joe Walker [:jwalker] (needinfo me or ping on irc) from comment > #44) > > OK, so the alternative to the command line flag is: > > > > We have a place in the UI to configure a set of origins for which security > > is turned off. This set of origins can contain simple wildcards (like '*' > > rather than full regexps). Setting origins using IP address is allowed. > > > > Security will be disabled for any request to an origin when the following > > requirements are met: > > 1. Devtools are open > > 2. The 'disable security' switch is on (and visible) > > 3. The request origin matches an origin configured for no security > > > > If devtools are closed when the switch is on, then we revert to security > > being enabled everywhere. The switch can not be hidden while it is enabled. > > > > The switch will have some red danger marker so you know there's something up. > > > > --- > > > > I think this is safer than a command line switch because it can't be > > forgotten and has a narrower scope. I think that once configured, it's > > easier to use because you don't need to restart the browser. I also think > > the requirement to have devtools open is extra protection against misuse by > > addons. > > > > Anyone disagree? > > How does one enable it for a Firefox OS device? It seems like Firefox OS should just be the same as Joe describes above for desktop. You would connect to the device via WebIDE and open the DevTools, disable security, and configure the origins as needed.
(In reply to Joe Walker [:jwalker] (needinfo me or ping on irc) from comment #44) > OK, so the alternative to the command line flag is: > > We have a place in the UI to configure a set of origins for which security > is turned off. This set of origins can contain simple wildcards (like '*' > rather than full regexps). Setting origins using IP address is allowed. > > Security will be disabled for any request to an origin when the following > requirements are met: > 1. Devtools are open > 2. The 'disable security' switch is on (and visible) > 3. The request origin matches an origin configured for no security > > If devtools are closed when the switch is on, then we revert to security > being enabled everywhere. The switch can not be hidden while it is enabled. > > The switch will have some red danger marker so you know there's something up. > > --- > > I think this is safer than a command line switch because it can't be > forgotten and has a narrower scope. I think that once configured, it's > easier to use because you don't need to restart the browser. I also think > the requirement to have devtools open is extra protection against misuse by > addons. > > Anyone disagree? Completely agree, this looks reasonable. I think UX should take a pass on it once they start - I'm particularly interested in visual cues to the user while the insecure mode is enabled.
+1 for fixing this, it's blocking me. I'm a dev, I understand the risks, I have a real use case that I don't need to explain because I'm sure there's many many others, suffice to say they exist and FF needs parity on this w/ other browsers. The solution described in the immediately prior comments would solve my use case fantastically. (And is superior to Chrome's global on/off implementation.) I also imagine it would be more difficult so dirty command-line option in the meantime would be really appreciated. Thanks all!
Whiteboard: [parity-ie][parity-chrome][parity-opera] → [parity-ie][parity-chrome][parity-opera][gaming-tools]
Priority: -- → P2
+1 also, this is blocking me from debugging with localhost
Another dev story. Imagine you are making a Desktop App that uses Gecko View. For better and more rapid development, you develop using Firefox's Dev tools. The Webview page uses GET/POST request to some server, completely bypassing CORS. The desktop App's gecko WebView is configured to not respect CORS also. This was a lgeit scenario for me, BUT, with Webkit [QtWebKit] and Chrome with --disable-web-security. QtWebkit has a function call for disabling web security as well.
(In reply to Joe Walker [:jwalker] (needinfo me or ping on irc) from comment #44) > Security will be disabled for any request to an origin when the following > requirements are met: > 1. Devtools are open > 2. The 'disable security' switch is on (and visible) > 3. The request origin matches an origin configured for no security I am open to attempting this out of my own personal frustration. :) :jwalker, any ideas where we would place the "disable security" switch, if it must be visible to be enabled? Normally we'd place things in toolbox options, but then it's hidden if you actually use a tool. :helenvholmes, any thoughts?
Flags: needinfo?(jwalker)
Flags: needinfo?(hholmes)
I imagined that it would be a toolbox button for the on/off switch and a text area in the options panel for the domains.
Flags: needinfo?(jwalker)
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #53) > :jwalker, any ideas where we would place the "disable security" switch, if > it must be visible to be enabled? Normally we'd place things in toolbox > options, but then it's hidden if you actually use a tool. > > :helenvholmes, any thoughts? I think having the ability to enable this sort of functionality at a top-level, all the time, shouldn't be necessary. What I propose instead is: 1. Within options, there's a flag to turn this on. 2. Once turned on, a flag appears in the toolbar saying that it's on. Maybe a label of some sort: "CORS security disabled", or whatever semantically matches what's in settings. http://cl.ly/3c1U2w261u43 3. Flag stays put and activated until you go back into options and turn it off again. This is just an idea. I'd also ask Brian for his opinion on stuff happening in the toolbar.
Flags: needinfo?(hholmes) → needinfo?(bgrinstead)
To ask for one more feature if it's easy to do(?): it would be good to still get warnings about CORS check failures even when CORS is disabled, so that one could use the disable mode to audit a web site and run through a number of CORS failing requests and log all of them. This would allow a developer to make a list of CORS fixes that are needed for a site, and hand that list in one big chunk to the server team. (In default mode, failing the request on first CORS error might fail the whole site and not be able to recover subsequent CORS errors, so it can become a "fix-one-run-into-another" kind of ping-pong messaging between developer and server teams with no easy way to estimate a priori when all fixes are done until the last one is resolved) Perhaps it might be possible to have a tristate (quiet, warnings, errors) type of handling of CORS?
If this is exposed through the toolbox UI then it'd need to behave like 'disable cache' does (i.e. the setting only applies for the current tab and only while the toolbox is opened). Once the toolbox is closed we'd need to re-enable normal security. I'm not sure if it's possible to disable CORS at that granularity from the platform, but the feature shouldn't be exposed through the toolbox UI unless if that is possible.
Flags: needinfo?(bgrinstead)
This is blocking Edge's CSS Usage to run in Firefox https://github.com/MicrosoftEdge/css-usage as their script needs to analyze style sheets from any origin but is currently blocked on accessing external files. Mentioning this user story, I am wondering how the devtools-open requirement works so well for this kind of automated testing. The CLI flag might be an easier way.
For what it is worth, in December 2015, Chromium people were discussing removing or weakening this flag: https://groups.google.com/a/chromium.org/forum/#!search/%22--disable-web-security%22/security-dev/KYCfKai_Hvc/ED0YUw-zDQAJ
(In reply to Harald Kirschner :digitarald from comment #58) > This is blocking Edge's CSS Usage to run in Firefox > https://github.com/MicrosoftEdge/css-usage as their script needs to analyze > style sheets from any origin but is currently blocked on accessing external > files. I filed bug 1262963 for this use case.
As Andrew linked in #59, Chrome has updated their implementation to require a `--user-data-dir` argument, i.e. running against a non-default user profile. It's a sensible way to ensure that nobody is running their "main" profile (with bank logins, Facebook, Gmail, whatever) with web security turned off. It still might be more prone to abuse than the design suggested in #44, but it has the merit of being much easier to implement, with nearly no impact on UI. (Chrome does add a warning banner on startup any time the flag is in effect, but I'm sure that piggybacks on other similar one-time dismissable popups, akin to the prompt to configure crash reporting on first run.)
(In reply to Joe Walker [:jwalker] (needinfo me or ping on irc) from comment #44) > OK, so the alternative to the command line flag is: > > We have a place in the UI to configure a set of origins for which security > is turned off. This set of origins can contain simple wildcards (like '*' > rather than full regexps). Setting origins using IP address is allowed. > > Security will be disabled for any request to an origin when the following > requirements are met: > 1. Devtools are open > 2. The 'disable security' switch is on (and visible) > 3. The request origin matches an origin configured for no security > > If devtools are closed when the switch is on, then we revert to security > being enabled everywhere. The switch can not be hidden while it is enabled. > > The switch will have some red danger marker so you know there's something up. > > --- > > I think this is safer than a command line switch because it can't be > forgotten and has a narrower scope. I think that once configured, it's > easier to use because you don't need to restart the browser. I also think > the requirement to have devtools open is extra protection against misuse by > addons. > > Anyone disagree? Here is a more or less bit modified alternative variant: 1. We keep the option to add URL's to a whitelist to disable security features for them. But instead of matching against URL's when they are requested we match against the URL of the address bar which forks down its whitelisted permissions to the whole tab (maybe with the exception of specific sandboxed iframes) as I think this approach is more practicable. 2. We add a global option to en-/disable this feature at all. 3. The address bar for affected sites gets colored red for its background with providing details in its info panel to give to the user feedback that the tab is insecure. I don't think this would require additional security from having the devtools open as this comes with the downside that they affect the site if being docked and this can end up in undocking/docking fuzzyness. Not sure if this also requires an entry in the options UI as these are developer options and developers might be able to do this all in about:config but I have no strong opinion about this.
My 2c: Ideally, I think it would be nice to allow even finer-grained permissions, as the add-on Corser does, and specify not just URLs that get additional permissions, but also what those permissions are, e.g. to let some files on my computer access some Moodle sites: file:///home/james/moodle-update-details/* file:///home/james/moodle-check-details/* - *://school.demo.moodle.net/* *://demo.moodle.net/* (Corser doesn't seem to provide all the permissions I need, though. Although I can write a script that loads a page in a frame, I can't get it to access the contents of the page.) However, I don't know how much additional complexity this would involve, and whether it would be worth the additional effort. I'll use Chrome's completely-disable-all-web-security feature in the meantime. If Firefox can do anything more fine grained than that, it would be great. :-)
Severity: normal → enhancement
It looks like a browser extension will work for my use case.
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, parity-ie, parity-opera
Whiteboard: [parity-ie][parity-chrome][parity-opera][gaming-tools] → [gaming-tools]
Product: Firefox → DevTools
I would really need this for e2e testing with Karma as a CLI option. I would really hate to use Selenium if I can solve the same with a few lines of javascript code in Chrome. I understand the concerns about end users disabling security, but a developer edition really could have this feature...
No longer blocks: 1569964
No longer depends on: dev-https-everything

Just to mention there will be changes in Chrome regarding to this: https://bugs.chromium.org/p/chromium/issues/detail?id=327804 Actually we already had changes a year ago, because I can no longer access error pages when trying to load a site with disabled web security, which is an issue for me, because I cannot parse the error page and write something about what kind of error happened. Another thing I had to do is using the --disable-site-isolation-trials flag, because without that I was no longer able to reach js engines of windows with different origins. Normally that is not encouraged and postMessage is used, but I do e2e testing with karma and pure javascript code instead of selenium, and this is the only way I know of without changing the code of the tested page or using a browser plugin.

I would love to see this.

My use case is developing locally on Microsoft Windows with an ASP.NET core web api backend and an angular frontend using Windows/NTLM auth.
I use Visual Studio Code and vscode-firefox-debug https://github.com/firefox-devtools/vscode-firefox-debug

I'd be happy to see this land in nightly and Firefox Developer edition.
I don't think we should worry about Chrome team switching away from
--disable-web-security flag to a more specific --disable-web-security-for-domain flag
In my case, it doesn't matter. I just use localhost.
However, I think we don't need to restrict this to localhost or a specific domain if we implement it just in aurora/nightly.

Thoughts?

Ethan, Arthur, assuming this falls into your team's purview, who would be a good counterpart on your team to get the platform side scoped and maybe prioritized within your roadmap? This is blocking some web compat work but also many enterprise use cases that want to call APIs from their development environment.

Flags: needinfo?(ettseng)
Flags: needinfo?(arthur)

(In reply to :Harald Kirschner :digitarald from comment #73)

Ethan, Arthur, assuming this falls into your team's purview, who would be a good counterpart on your team to get the platform side scoped and maybe prioritized within your roadmap? This is blocking some web compat work but also many enterprise use cases that want to call APIs from their development environment.

Harald, thanks for reaching out.
Christoph (ckerschb) might be a good candidate to help scope and prioritize this requirement. Let me discuss this with him and/or the team first. I'll get back to you soon (leave my needinfo as a reminder).

(In reply to :Harald Kirschner :digitarald from comment #73)
Harald and Christoph discussed this bug offline.

  • There is a pref to disable CORS: content.cors.disable.
  • The pref is global to Firefox. Please use it cautiously.
  • We're considering to combine the pref with Containers to limit its effect within development tools.
Flags: needinfo?(ettseng)
Flags: needinfo?(arthur)

I found some docs for that. If I'm reading them right, it's the opposite of what's desired here: that pref makes every CORS request fail; the desire here is to let every CORS request succeed without any checking.

(In reply to Matt McHenry from comment #76)

I found some docs for that. If I'm reading them right, it's the opposite of what's desired here: that pref makes every CORS request fail; the desire here is to let every CORS request succeed without any checking.

Christoph, could you help clarify it? Will the pref be helpful here?

Flags: needinfo?(ckerschb)

(In reply to Ethan Tseng [:ethan] from comment #77)

(In reply to Matt McHenry from comment #76)

I found some docs for that. If I'm reading them right, it's the opposite of what's desired here: that pref makes every CORS request fail; the desire here is to let every CORS request succeed without any checking.

Christoph, could you help clarify it? Will the pref be helpful here?

It is not just about CORS. For example I open google.com in a new window, reach the javascript engine of that window directly, type the keywords and send the form. I use this for end to end testing without selenium, but it can be used to write bots too.

(In reply to Matt McHenry from comment #76)

I found some docs for that. If I'm reading them right, it's the opposite of what's desired here: that pref makes every CORS request fail; the desire here is to let every CORS request succeed without any checking.

Ah indeed, it's the opposite, it will fail all CORS checks; Anyway, I guess it would be good if you could assemble a list of security checks you want to disable and then we can take it from there. As discussed, disabling security checks browser wide obviously bears risks, so ideally we could bound them somehow. E.g. by adding a new Developer-Container or something like that. Again, while technically it's not hard to add prefs to disable whatever security checks, it might be tricky to bundle that information in some meaningful way so the Developers are actually aware of the risks too.

Flags: needinfo?(ckerschb)

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #79)

Ah indeed, it's the opposite, it will fail all CORS checks; Anyway, I guess it would be good if you could assemble a list of security checks you want to disable.

  1. CORS
    1.1 <canvas> Access Denied
    1.2 <img> Access denied
    1.3 <iframe> Access denied
    1.3.1 (includes access to parent page)
    1.4 window.opener Access denied
    etc...
  2. file:// Access denied
    2.1. allow xhr/fetch for file://
    2.2. treat <script>, <link> (stylesheets), canvas, etc... using file:// as belonging to all possible URLs.

1.X use cases:

  • Developing main a website locally but the servers are external but inside the network (E.g. 10.0.0.0/8)
    ** Or with a seemingly public IP although routed through VPN (developing locally against staging servers, for example).

2.X. Use cases:

  • Developing a website locally and simulating a server returning static data without the need of the server itself. Much faster (less CPU usage over conditionals), less RAM usage, no need to makeshift some random server, mistaken commits won't open unwanted vulnerabilities (E.g. special code in server due to this limitation accidentally kept on) and easier to develop the website before there's any server at all.

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #79)

and then we can take it from there. As discussed, disabling security checks browser wide obviously bears risks, so ideally we could bound them somehow. E.g. by adding a new Developer-Container or something like that. Again, while technically it's not hard to add prefs to disable whatever security checks, it might be tricky to bundle that information in some meaningful way so the Developers are actually aware of the risks too.

I'm perfectly fine with restricting this feature to container configurations and/or limit the feature to nightly+dev_edition but I do feel a heavy need for it.
If you want not to restrict to certain browsers, that's better, though.
These restricting options can even live behind about:config and I'm fine with that.

Again, I just want it.

First, Bruno's two broad categories of use case might be best treated as two separate tickets. I think the first use case (disabling CORS protections) is appropriate for this ticket, but I'm pretty sure supporting fetch against file:// URLs is already its own ticket. (No time to dig it up ATM, sorry.)

Second, I am not perfectly fine with restricting this to a dedicated nightly and/or dev edition. The kinds of tests that require this feature aren't limited to developer machines -- sometimes I'm working with a customer on their machine and need to test out how a feature will behave, after I've finished the 2 months of paperwork required to get the server owner to put us on their CORS whitelist.

Moreover, sometimes I'm in an environment where Firefox ESR is on the "approved software" list but special dev builds are not. I'm in no position to get the dev/nightly builds approved, so if it's not in the official release channel -- behind a battalion of command line switches, dire warnings, "yes I'm really sure" buttons, etc -- then I might as well not have it at all.

See also: bug 1266960

I just wanted to chime in and add that the number one use case in my world for this is e2e testing a deployed application that uses APIs that become restricted in cross-origin scenarios. I am working on a course regarding testing Progressive Web Apps and many features are only enabled under HTTPS with valid certs. To make e2e testing easier, I test against a deployed URL (Netlify) which means I don't have to step the student through trying to generate self-signed trusted certs for CI / local testing, etc. we can just rely on the trusted certs in the deployed environment (plus, it's much more production-like to test against than a localhost URL).

Using Cypress, I can test in Chrome/Chromium browsers with disableWebSecurity configuration (which uses --disable-web-security) but this is unsupported for Firefox due to this issue. This means there are various APIs/scenarios I have to exclude from the FF e2e test run (window.Notification API, window.caches, service workers) since they will fail with cross-origin iframe access errors. In my course, I'll just have to explain that you can't test certain features in Firefox due to web security issues but of course it would be fantastic to have complete parity between FF, Edge, and Chrome test runs.

For more info regarding Cypress and disabling web security, see https://docs.cypress.io/guides/guides/web-security.html#Disabling-Web-Security

This is still a pain point with FF. My use-case is also related to test automation. We do allow localhost development without HTTPS as it is easier to setup, but with Playwright where I have not found a way to modify CORS settings I cannot run the tests against firefox in localhost. There is additional hitch in enabling the HTTPS for my local use as I would need to overwrite the HTTPS also to Azure AD B2C account to have HTTPS redirect address for localhost instead of http. If I change that to HTTPS, others in our dev team are also forced to setup HTTPS for the authentication to work.

Sure I could then go out of my way to hack the code to disable authentication from both the React App, backend rest API and the test cases, but then I am not anymore running the same test case.

(In reply to Antti Viita from comment #84)

This is still a pain point with FF. My use-case is also related to test automation. We do allow localhost development without HTTPS as it is easier to setup, but with Playwright where I have not found a way to modify CORS settings I cannot run the tests against firefox in localhost. There is additional hitch in enabling the HTTPS for my local use as I would need to overwrite the HTTPS also to Azure AD B2C account to have HTTPS redirect address for localhost instead of http. If I change that to HTTPS, others in our dev team are also forced to setup HTTPS for the authentication to work.

Sure I could then go out of my way to hack the code to disable authentication from both the React App, backend rest API and the test cases, but then I am not anymore running the same test case.

Same here, I need this for e2e testing mostly. For now I just run the tests in Chrome, but it would be nice to be able to run them on a different browser too.

There are several large companies I have noticed (ours included) Fortune 500 that are starting to use Cypress as their main testing platform, the power to run e2e tests against all supported browsers is a major appeal. Right now, we currently support the latest version of all major browsers. Firefox, Chrome, Safari, Edge, and to some extent IE11. IE11 is being phased out by the end of this year.

If we can't ensure success in Firefox, then we might have to consider stopping support for Firefox as well.

It might make sense to expose this as a WebDriver session capability, similar to acceptInseureCerts. That would allow standardising the behaviour to be the same in all browsers, rather than relying on the exisiting solutions that depend on unstable browser-specific flags. It would also make it difficult/impossible to accidentially run this with a normal user profile since you'd need to both enable automation and create a WebDriver session. For Cypress in particular I don't think they are currently using WebDriver, but I think they do use CDP for some functionality, so it seems plausible they would be able to use WebDriver-BiDi in place of CDP.

I've filed https://github.com/w3c/webdriver/issues/1583 for this issue; please comment there if the description doesn't accurately reflec your use cases here.

I also note that setups which depend on disabling security features are inherently fragile in that accidentially breaking sites by incorrect CORS-confguration is common, and a testing setup relying on disabling CORS is going to be unable to detect such bugs.

I'd like to see a way to disable CORS for requests (say via fetch) performed from the Developer Console interactive interpreter.

Severity: normal → S3

+1 to this feature
Currently blocks or development and test at work with Firefox.extensions found in addons.mozilla.org doesn't work and compile a version of Firefox to remove that layer of security is not an option due to the time/effort required.
Please I hope this bug/feature will take more relevance to help us (developers) to adopt Firefox easily.
Thanks

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: