[oelmekki]

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

[minitech]

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

[cjcampbell]

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.

[majewsky]

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?