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

Status: NEW

(DevTools :: General, enhancement, P2)

Description

[Jukka Jylänki]

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.

Comment 1

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

This seems like a terrible idea to me.

Comment 2

[Jukka Jylänki]

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.

Comment 3

[:Harald Kirschner :digitarald]

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.

Comment 4

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

ni?ing Mark, who is our devtools security person.

Comment 5

[Doug Turner (:dougt)]

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.

Comment 6

[Jukka Jylänki]

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.

Comment 7

[Jeff Griffiths (:canuckistani) (:⚡︎)]

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.

Comment 8

[Mark Goodwin [:mgoodwin]]

(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.

Comment 9

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(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.

Comment 10

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(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.

Comment 11

[Jukka Jylänki]

(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.

Comment 12

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(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.

Comment 13

[Jukka Jylänki]

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.

Comment 14

[Joe Walker [:jwalker]]

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.

Comment 15

[dbuc]

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.

Comment 16

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(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)

Comment 17

[Thibault Nélis]

+1 for basic dev scenario.  It's been more or less explained above, but here's the tl;dr that makes this obvious and necessary:

- Dev A writes a client against an HTTP API on server X, outside of their control.

- Dev A runs a test suite or local version of the server for testing first (because test suites or open-source/distributable packages of servers are *always* available).

- Dev A subsequently wants to test against the real server X before pushing the code to the production site.  He either wants to keep the client running locally, or run it on a staging site with a domain not in the CORS policy of server X.  Any of which seem perfectly reasonable to me.

If you chuckled on the previous point, then it's not just a good and reasonable integration testing practice, it's simply required.

- Once everything works, Dev A pushes the client to the production site.  Its domain is in the CORS policy of server X, and thus normal users don't need to enable the dangerous dev-time setting proposed here.

This is all without bothering the operators of server X (whitelisting dev/staging sites on production servers is the actually bad idea anyway, not the proposed setting).

Comment 18

[dbuc]

This should *definitely* be in the Developer version of Firefox - it's basically the perfect example of a purely developer-centric feature that makes various dev workflows much easier to tackle.

Comment 19

[sam]

+1: this is also something that blocks development at my company. One thought I had was to make a fork with security disabled such that you would only be able to access local ports.

Are there any pointers regarding where to look if someone wanted to work on this disabled security feature?

Comment 20

[Nicolas Peifer]

Another use case: I'm currently trying to extract (and process) data from a foreign web site using JavaScript/AJAX. I don't know any other (simple) possibility than using my browser for this purpose. Hence the --disable-web-security feature would be really nice.

Comment 22

[Makc]

+1 for this.

People all over the internet suggest that setting security.fileuri.strict_origin_policy to false will do this, and you have to dig link through the link before you get here and see it is not implemented. If you end up rejecting this idea, please consider putting clear message that there is no way to turn CORS off somewhere where google can spot it easily. And yes, people will have to use chrome then.

@Falco Prieseni, there's a plenty of ways you could do that, e.g. https://www.npmjs.com/package/request

Comment 23

[Joe]

Attachment: 0001-disable-CORS.patch

This seems to disable CORS checking by Firefox.

Comment 24

[sp]

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?

Comment 25

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(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.

Comment 26

[Joe]

(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.

Comment 27

[sp]

(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.

Comment 28

[javascriptjedi]

The lack of these feature is wasting my time.  How about letting developers do what they want instead of treating them like children?

Comment 29

[Ben Bucksch (:BenB)]

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

Comment 30

[Ben Bucksch (:BenB)]

... in favor of bug 1121824

Comment 31

[Makc]

@BenB, this is both crazy story and crazy reasoning :) let's not ban knives because you cut yourself once, k?

Comment 32

[sp]

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.

Comment 33

[Makc]

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.

Comment 34

[Joe]

(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.

Comment 35

[Joe Walker [:jwalker]]

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.

Comment 36

[Makc]

@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.

Comment 37

[dbuc]

(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.

Comment 38

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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.

Comment 39

[Joe Walker [:jwalker]]

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.

Comment 40

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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.

Comment 41

[Mark Goodwin [:mgoodwin]]

(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?

Comment 42

[Joe Walker [:jwalker]]

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?

Comment 43

[Mark Goodwin [: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.

Comment 44

[Joe Walker [:jwalker]]

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?

Comment 45

[sp]

(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

Comment 46

[Jukka Jylänki]

(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?

Comment 47

[Joe Walker [:jwalker]]

(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.

Comment 48

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(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.

Comment 49

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(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.

Comment 50

[drew]

+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!

Comment 51

[kittimiyo]

+1 also, this is blocking me from debugging with localhost

Comment 52

[Peter Petrov]

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.

Comment 53

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(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?

Comment 54

[Joe Walker [:jwalker]]

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.

Comment 55

[Helen V. Holmes (:helenvholmes) (:✨)]

(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.

Comment 56

[Jukka Jylänki]

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?

Comment 57

[Brian Grinstead [:bgrins]]

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.

Comment 58

[:Harald Kirschner :digitarald]

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.

Comment 59

[Andrew McCreight [:mccr8]]

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

Comment 60

[Jet Villegas (inactive)]

(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.

Comment 62

[James B]

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.)

Comment 63

[sworddragon2]

(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.

Comment 64

[jeg+accounts.github]

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.  :-)

Comment 65

[jeg+accounts.github]

It looks like a browser extension will work for my use case.

Comment 66

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 67

[László Jánszky]

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...

Comment 68

[echosa]

I just came across this discussion while looking for a way to get past CORS issues in Firefox 65. I am a developer, but in this case, that has no bearing. "Normal" users/non-developers might also need a way to get past CORS issues. Example, which I'm experiencing right now:

As a user, I'm attempting to watch SlingTV in Firefox. (Note: they only officially support Chrome and, by default, the web app doesn't work in Firefox. However, up until now, simply changing my user agent to Chrome in a profile specifically for Sling has allowed it to work so I could watch shows.)

Today, I'm unable to even login to SlingTV. When I click the login button, I get a CORS warning:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://webapi-grn.p.sling.com/ums/v5/sessions?client_application=ottweb&format=json&locale=en. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

I assume this is because they do not have their servers configured correctly. I have no control over this, neither as a user nor a developer. I have contacted their support about it but, honestly, I don't expect this to get fixed, or at least not anytime soon. (I'm assuming it works in Chrome, but I don't have Chrome installed to see.)

I mention this use case here because the rest of the discussion here has all been developer-focused, but I don't think that's enough. If non-developer users can't access and use the services they subscribe to, then Firefox isn't useful for them and they'll be forced to use other browsers. As much as I hate Firefox being a second-class citizen to some sites and services, the reality is that, at least for now, it is. It'd be nice if we could work around that.

I could install Chrome just for watching Sling. I might end up doing that because I have to. Heck, even if this issue is fixed in Firefox, it won't be for sometime, and I'm not just going to not watch Sling that whole time, so chances are I'll have to install Chrome (or some variant thereof) for this. I'd rather not have to. I'd rather everyone else not have to. Ideally, Firefox will be a browser for everyone for everything. Right now, it isn't, and while that's not completely Firefox's fault, I'm hopeful that Firefox can compromise and workaround these sorts of issues - both for developers and non-dev users.

Comment 69

[echosa]

Follow up: Good news! (sort of?) Sling isn't working in neither Brave nor Chrome itself. Same CORS error. I call this "good" because it gives me hope that they'll have to fix it on their end.

That said, I still think my comment above might still be valid. There have been times when I've had to go to some sort of Chromium-base browser to use sites and services because of CORS issues that, as a user, I have no way to fix.

However, I'll say this: if all Chromium-based browsers are also blocking these requests now, then there's not reason for Firefox to have to change for end users. If a service doesn't work in any browsers, they'll have to fix it, which will hopefully fix it for Firefox and not just Chrome.

That said, being able to bypass CORS for development purposes is still a good and valid idea. If my two comments here are worthless now, apologies for the noise.

Comment 70

[echosa]

Welp. Sorry for the noise. Apparently, my VPN is not allowing Sling to work in any browser. Turning off the VPN has it working again. :-/ I'll show myself out now.

Comment 71

[László Jánszky]

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.

Comment 72

[Kus]

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?

Comment 73

[:Harald Kirschner :digitarald]

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.

Comment 74

[Ethan Tseng [:ethan]]

(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).

Comment 75

[Ethan Tseng [:ethan]]

(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.

Comment 76

[Matt McHenry]

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.

Comment 77

[Ethan Tseng [:ethan]]

(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?

Comment 78

[László Jánszky]

(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.

Comment 79

[Christoph Kerschbaumer [:ckerschb]]

(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.

Comment 80

[brunoais]

(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.

Comment 81

[James B]

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.

Comment 82

[brunoais]

See also: bug 1266960

Comment 83

[kamran]

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

Comment 84

[Antti Viita]

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.

Comment 85

[László Jánszky]

(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.

Comment 86

[Christopher Clark]

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.

Comment 87

[James Graham [:jgraham]]

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.

Comment 88

[sdaniele3]

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

Comment 89

[grayedfox]

Nine years on and still no switch -- if Firefox wants to stay in the game -- it needs to make adoption easier, not harder. If running E2E tests against Firefox continues to require lots of workarounds and jank this just increases the barrier for adoption.

To whom it may concern - please consult your team/org and make the case to prioritise this higher if possible. Been a long enough wait.

Comment 90

[info]

+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

Comment 91

[mellfang36]

+1, this happens a lot when developing on localhost, and not having access to the server to add CORS headers/ the CORS headers being buggy.

Comment 92

[gorgulenkozxc]

+1, I hate having to switch to chrome every time I need to make a userscript for an iframe protected by CORS. Addons won't help in such cases.

Comment 93

[Vectorspace]

hacks.mozilla.org has recently published an article that Puppeteer now has official Firefox support. https://hacks.mozilla.org/2024/08/puppeteer-support-for-firefox/

I opted to take some time and try it myself, but quickly ran into this issue - the application I want to test, the server requires CORS which doesn't seem to work with Puppeteer request interception. With Chrome I can set the cli flag to disable CORS, but I can't do that for Firefox.

Comment 94

[Julian Descottes [:jdescottes]]

(In reply to Vectorspace from comment #93)

hacks.mozilla.org has recently published an article that Puppeteer now has official Firefox support. https://hacks.mozilla.org/2024/08/puppeteer-support-for-firefox/

I opted to take some time and try it myself, but quickly ran into this issue - the application I want to test, the server requires CORS which doesn't seem to work with Puppeteer request interception. With Chrome I can set the cli flag to disable CORS, but I can't do that for Firefox.

Hi, can you share more details, especially which API are you using in puppeteer? If it is Request.respond, could you just try adding headers to allow CORS (Access-Control-Allow-Origin set to * for instance?).

Comment 95

[Julian Descottes [:jdescottes]]

In parallel, can you also check if the setting the preference content.cors.disable in Firefox fixes the issue?

Edit: actually it seems that the pref fully disables CORS requests, instead of disabling CORS checks, so probably a no-go here.