Hacker News Reader

Comment by sombremesa | Hacker News Reader

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?

View on HN

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.

Reply on news.ycombinator.com