DEV Community

Cover image for CORS Hides Real Bugs
Parker Drake for Focused Labs

Posted on • Updated on • Originally published at focusedlabs.io

CORS Hides Real Bugs

Before You Scroll

If you're here because you have a CORS error and you think it's hiding your real problem, run this command:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-web-security --user-data-dir=~/temp/chrome

This will start up a Chrome instance with web security turned off, which gets CORS errors out of the way leaving you free to debug your response (assuming the CORS error itself isn't your problem).

For the bug in this blog, we spent about 4 hours debugging before we ran the above command, and then had the issue fixed an hour later.

The Background

Recently my pair and I implemented a feature to process some data with a long running GraphQL mutation (about 2 minutes to return a response on a production size data set). There are better ways to do this without such a long-running request, but this particular action happens rarely enough we just went with this approach and plan to revisit it later.

The Bug

On our development machines, everything would run just fine, but in our higher environments, we'd get this lovely error in the browser console:

Access to fetch at '[OUR API]' from origin '[OUR FRONTEND]' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Some other interesting things we noticed:

  1. There were no errors in the server logs.
  2. The data processing was actually happening just fine, but the response was buggy.
  3. We'd get this message exactly 1 minute after we fired the request, every time.

The Fix

Turns out, because of the long running request, we were bumping up against 2 different timeout limits in our stack, one at our ingress controller, and one at our DNS. It makes sense that we couldn't replicate this locally, since in our dev environments there is neither ingress nor DNS. Tweaking those limits was all we needed. Once we launched into a CORS free world using this command:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-web-security --user-data-dir=~/temp/chrome

Everything started falling into place!

Top comments (5)

Collapse
 
jamesmcmahon profile image
James McMahon

Chrome is so sneaky!

That command line flag is seriously something I've learned and forgotten about around 5 times now.

Forgetting again and again

Collapse
 
austinbv profile image
Austin Vance

I just set chrome to always use that flag? Could that cause a problem?

Collapse
 
andrewbridge profile image
Andrew Bridge

I'd be wary about using a browser with a flag named "disable web security" to browse the web normally. As it suggests, it's disabling mechanisms that protect you from certain attack vectors.

It'd be far better to fix the CORS issues in your setup than bypass them, but if you can't, I'd only use the browser with that flag for code you own.

Collapse
 
crtaylor243 profile image
Ryan Taylor

For Windows users:

C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir=%TEMP%
Enter fullscreen mode Exit fullscreen mode
Collapse
 
katydidknot profile image
katydidknot

πŸ”₯