CORS Policy and the Imperfections of Cloud

written by Joel Reed 9/24/2020

Like all things tech, the cloud is not without its flaws, oversights or even bugs. With the main players in the cloud space being Google, Microsoft, and Amazon and their access to a large amount of resources, it is easy to have the perception that they have it all figured out. In general I’d agree with that statement, but their teams are human, mistakes and limitations exist; and this article highlights one of those limitations.

At NephoSec, we had worked up an application architecture making use of GCP’s Cloud Run running a React Frontend that pointed it’s heavy lifting at GCP’s Cloud Functions using Python runtime. As with many other modern web applications you end up having to comply with CORS (Cross-origin Resource Sharing) Policy, which is exactly where we found our problem in GCP. 

While CORS is extensively documented and relatively easy to understand (even for someone who isn’t an avid Frontend Developer). Here is a really good writeup on CORS by Codeacademy for anyone interested. Basically CORS prevents one source from acquiring resources from a separate source or a new origin in a different domain, and it does so by:

  1. Browser creates a Preflight check specifying the nature of the users request, such as the Origin, Method, Content-Type, and more.
  2. The remote server validates that the request type is “OPTIONS” and based on the supplied headers that the Origin is allowed to make the request.
  3. If applicable; the remote server returns a “204” status allowing the request.
  4. Finally, the Users intended request is made.

To start talking about where we found our issue, we have set up our Cloud Functions according to the GCP Documentation, we make our request from the frontend and were met with “Access to fetch at `remote origin` from origin `request origin` has been blocked by CORS Policy”. In our testing we would log the Cloud Functions errors and nevertheless the logs didn’t point to anything being wrong with our Cloud Functions, and the browser was still reporting CORS errors with every type of request we tried to make. Digging deeper, we took a look at the networking tab of the inspect tool, finding that our Preflight request was successfully returning a “204”… So why the CORS Error? In the GCP Stackdriver logs, we were getting the reports that our Cloud Functions were crashing; but no information on the cause of the crash. This led us to believe that our issue did remain with CORS for some time until we stripped our functions down to nothing and discovered a bug in our code.

While ultimately this issue was caused by a bug in our code (it happens), the limitations of the logging functionality that was present with Cloud Functions pointed us in the wrong direction for debugging, this issue has since been partially resolved (still under investigation by Google) and our engineering team has learned a valuable lesson.

The final takeaway is; as with all humans and Cloud technologies none are perfect, and with the size of the Cloud, bugs and inconsistencies are common. Troubles like this are a good reason to have a partner in Cloud, NephoSec can be that partner of choice allowing you Cloud with Confidence.

You May Also Like