Hacker News Reader

Comment by dak1 | Hacker News Reader

I would love to use Firefox more for dev, but until it has a first class way to disable CORS, I can't. "CORS Everywhere" is not sufficient (it alters responses, but does not actually disable CORS, which doesn't cover all needs).

Chrome I can at least disable CORS via the command line, and Safari does it best by putting it in a Developer menu that I can easily toggle.

Firefox's dev tools also seem to still be behind — I haven't seen a good way to inspect WebSocket frames, for instance.

I would really prefer to use Firefox due to Mozzila's stances on privacy, especially in contrast to Google; however, I have to use the tool that lets me actually get work done.

View on HN

I love using Firefox as my daily driver, and I can always pop open chrome if I really have to. What kind of life do you lead where your browser needs to have CORS constantly disabled?

This can be helpful in development scenarios. I’m supporting a team that uses localstack to support local development against some AWS services. Unfortunately, the CORS settings for localstack break the development environment. With Chrome allowing them to disable from the command-line, I can provide a shortcut to launch with degraded security, no plugins, no user settings, etc. My only wish is that Chrome would make it more obvious that it’s running with these protections disabled.

>My only wish is that Chrome would make it more obvious that it’s running with these protections disabled.

I know this is beginning to become off-topic, but why? Presumably, if you're using a flag that has to be run from the command-line, you're either doing it on purpose or using hardware you don't own (and a keylogger is a much greater risk than anything else at that point)

I can't speak for OP, but for me the problem is that I likely already have normal Chrome windows open when I start a "special" Chrome instance with a private profile and other settings. So now when I see a Chrome window I would like to be sure whether it's my normal user profile or the special profile.

In practice, it's not a problem for me, because the presence or absence of my usual row of extension icons and profile photo is enough of a clue.

But I could see where someone who doesn't normally sign into Chrome, or who doesn't have very many extensions in their normal Chrome profile, could have trouble distinguishing it from their a profile. The windows will tend to look pretty similar.

Exactly. If I need to run a browser in a special configuration, I want to take every precaution to avoid using it for anything but the intended purpose. Since I disable my profile and extensions, I get similar cues.

The problem I see is that not everyone takes the same precautions. And plenty of developers accumulate these sort of tweaks and hacks in their daily driver without realizing or remembering that they've crippled their own security posture.

From a UX perspective, my preference is to make it clear when normal security mechanisms are disabled.

Why not just configure your server or a proxy to add the necessary headers that unlock CORS restrictions.

Because in real companies the IT department needs a real good reason, or a large number of devs that need it, to reconfigure a server that way.

If you're not a lone wolf, or working in the SV bubble, the IT and security departments are going to tell you to go pound sand.

Not really. In lots of relatively large companies there is a good relationship between infrastructure, development and security teams and they will work to find a solution that works for everybody.

This is how it works at my work.

CORS is allowed while running locally and then set while running in development and finally production.

It's 2 lines of code with most modern web frameworks with junior level knowledge required. Actually, any people with decent dev skills (any people that receives money for code should...) add a conf switch for that since the begining of the project.

I don't buy your comment at all.

Because having code that behaves differently on development and production is never a solution, it's a workaround. Having bugs that can't be reproduced locally is the worst thing that can happen to a developer. So yeah, you can _just_ put environment settings if you have no other possible way, but you should really avoid it if there is any other one (like using chrome with CORS disabled, here).

Disabling CORS in your browser is not representative of production. Serving CORS headers is.

Mentioned this in another response. In this case, that requires the addition of another component. The app itself is serving a valid CORS policy. The stub we're using to support S3 development offline (LocalStack) ignores the configuration it's passed.

I agree with you that fixing the headers (via a proxy in this case) is the right solution. I'm just not able to prioritize right now.

Beyond that, there are always going to be occasions where developers, security analysts, and testers need to bypass default security enforcement. I'd like to see every browser provide a way to make these adjustments for a one-off session (e.g., via a command-line switch). It's an efficient solution that I can offer when I come across a nasty hack living permanently in a developer's web configuration.

By that same argument, using Chrome with CORS disabled is just as bad, if not worse. If you only test in Chrome with CORS disabled, how do you know that CORS works at all?

The web server is configuring CORS policy properly, but the browser is making client-side calls to localstack. As far as I can tell, localstack has hardcoded a CORS policy that is a mismatch for the requests being sent.

The cleanest solution is to extend the dev pipeline with a proxy for localstack. It won't take me long to knock that out, but it's not something I can prioritize at the moment.

Not sure if it might have this but have you tried using Firefox Developer Edition? I would suggest if disabling CORS is missing to request it for Firefox Developer Edition. Its Firefox bleeding edge with some developer focused plugins out of the box.

You should be setting your server to set cors to allow all not disabling it in your browser.

This is what we do while running docker for local development with node.

At the very least, CORS should be disabled for localhost. I build interfaces using create-react-app, which launches a dev server on localhost:3000 (useful for things like live reload), making requests on a go api on localhost:5000. On production, both are on :80 and the backend serves frontend production files. This is annoying to alter the application code just to handle dev environment (although, this already happen in many other places, so it's not critical).

I set up a separate profile for debugging stuff - you may want to do this anyway since you'll be free to install development extensions willy nilly.

Then you can change the theme for that profile which makes it obvious which instance you're using.

I do the same for myself, including an obnoxious theme. Not all developers are this cautious.

Chromium pops up some yellow bar with a warning when you use those flags. Isn't Chrome doing the same?

There's a temporary warning.

Most folks set up a little proxy--or configure CORS if the other end of the pipe is owned or cooperative--rather than throw out the baby with the bathwater due to inability to disable an important security measure.

angular dev environment already comes with that proxy incorporated.

Curious what use cases you have for disabling CORS?

Is it for 3rd party domains and APIs or response that you control? Either way, controlling it in browser doesn't sound like the right way.

For testing a client side app in development locally against a remote API, disabling cors is really handy.

I have localhost.com in my hosts file and a local web server to run around it, but it's still really frustrating not being able to turn it off entirely.

Obviously I don't have context on your work, but in general, do you have control over remote API?

If yes, you can setup different environments (dev, staging, production) and set CORS accordingly for each of them.

If no, how is it working in production?

I develop browser based video games that talk to a central API that I control.

I mostly have the setup you describe, and most development happens against a CORS-free staging server. But it's often necessary to build a local prod version that is identical to the live version for debugging or analysis, that plays against real players and reads/writes to the same data store.

It's an edge case, and in the past when I've done web development simply turning off CORS on staging has trivially solved any issues. But it does feel a bit like the developers of the browsers have chosen not to include the feature in a "we're smarter than you, trust us, you don't want this" kind of way. For the most part, they're probably right.

I see.

Just a wild idea that I haven't tried yet:

Would it work if you configure your etc/hosts to point production domain to localhost and open the production domain in the browser?

I'm gonna try this when I get free time.

This is one of my gotchas (and I prefer to do so from the commandline). I also need a good extension manager and a session/tab manager. The extension manager makes it easy to disable extensions that are only used occasionally. The session manage makes it easier for me to keep tab count down.

I have found a few session manager options on Firefox but most suffer from permission bloat and poor UI.

Last I checked, there was nothing to make it easier to manage add-ons.

I just switched to FF and had a similar requirement. I found "Session Sync" to be a good replacement for what I used in chrome (FreshStart).

Thanks. I haven't checked in a few months, so I'll give it a look.

Out of couriosity, wouldn't it be an option to implement CORS? From my understanding, it's just a few static headers.

Agreed with the missing WebSocket inspection.

Reply on news.ycombinator.com