Understanding and Resolving CORS Error

Cross-Origin Resource Sharing (CORS) is a mechanism or a protocol that allows devices on one domain to access resources residing on other domains.

Generally, for security reasons, browsers forbid requests that come in from cross-domain sources. However, there could be cases where you want to overcome this and access cross-domain resources, and CORS makes this possible.

There's another concept known as Same-Origin Policy (SOP) which enables resource sharing on similar domains. In this guide, we'll discuss the SOP and how it helps to secure websites. We will also discuss how CORS extends the flexibility and adds pace to the SOP.

Same-origin policy (SOP)

The Same-origin policy is developed as a security mechanism for browsers to protect resources from malicious attacks. SOP allows resource sharing (data exchange) between two objects having the same origins.

This means that the origins of two websites should be the same if they want to share resources. For two websites to have the same origins, the websites should have the same domain, port number, and protocol type. If any one of the three properties is found differently, then the sources are considered different origins.

While SOP is considered a restrictive system, it is highly secured eliminating potential attacks on websites through cross-domain resources.
SOP offers security to websites but can also be a huddle to interact with third-party websites.

Many dynamic websites regularly engage in cross-domain resource sharing with trusted websites and subdomains.
With SOP in place, access to cross-origin websites is restricted, and controlled access to resources can be possible using Cross-origin Resource Sharing (CORS).

Cross-origin Resource Sharing (CORS)

CORS is introduced to provide easy and quick access to subdomains and trusted third parties. CORS enables controlled resource sharing between cross-domain origins, as discussed earlier.

The browser and cross-origin website you are trying to access collectively exchange HTTP headers that define trusted web origins and associated properties for access control, as defined by CORS specifications.

CORS offers controlled access to cross-domain websites and hence is well secured. CORS is generally implemented to tackle limitations introduced by SOP. However, if poorly executed, CORS can cause severe security risks. Improper configuration of CORS may present some challenges and errors.

Let us learn more about CORS errors and best practices to avoid them.

Understanding and Fixing CORS Error

CORS is implemented on the server-side; it can’t be reconfigured on the client-side. The CORS behavior, commonly termed as CORS error, is a mechanism to restrict users from accessing shared resources.

This is not an error but a security measure to secure users or the website which you are accessing from a potential security bleach.
This bleach may occur due to incomplete or improper HTTP headers on the client-side implementation(eg. missing authorization data such as API key).

Best Practices to Avoid CORS Errors

Let's discuss some of the best practices for avoiding CORS errors by using a Custom Field Extension in Contentstack.

Proxy the API Request While Using External Calls in an Extension

CORS proxy can be a helpful solution to make cross-origin requests. The proxy layer sits between your request and its destination without knowing the request’s origin.
Thus, though the request comes from an unknown source, the CORS proxy makes it seem that it's a request from an allowed location.

Here is the list of CORS-Proxy which you can use for your website to learn how to do this

Free Proxies can be great for testing, but it's not advisable to rely on a free third-party tool for something that you’ll  be using in production. In such cases, a more stable solution is to call the API from a server and make the data available on the client side.

Use a Serverless Function

A more commonly used solution is to use a serverless function. It is an alternate way to proxy your requests, but unlike the above method, instead of relying on a free third-party service, you can build your micro-infrastructure to call a web service and feed data to an API endpoint.

Popular serverless functions include AWS Lambda, Azure Functions, and Google Cloud functions. These services allow you to get just enough server space to run a function or two as we don’t need much space to run a function that calls a web service to return some data.

To understand this better, let's consider a use case:

A user wants to create an extension in Contentstack which will fetch maps data from the Google Maps API to get data related to longitude and latitude within your entry.

The user has to follow the steps below:

  1. Create a custom extension in Contentstack using the UI extension SDK. This extension will make an API call to the Google Maps API to fetch the data in your entry.
    The request will fail due to the cross-origin policy set at Google’s server, which won't let you fetch the data, and a CORS error will occur at your client-side.
  2. To solve this problem, you can create an API Gateway URL in AWS with CORS enabled to serve the responses from the Google Maps API with our AWS lambda function.
  3. The extension that we have created will make an appropriate call i.e., GET, POST, and so on, to our API Gateway URL & trigger our lambda function.
  4. The AWS lambda will then return the maps API response to our client-side. This will fetch the map data from Google Maps within your entry in Contentstack.

Note: For external hosting of the extension source code, the 'allow-same-origin' option will be enabled. Here, the origin refers to the domain where you've hosted the extensions. Also, ensure that the response header has the exact origin URL passed in the request header.
For Contentstack-hosted extensions, the iframe's origin will be null as we don't enable the 'allow-same-origin' flag.

CORS Issue in Frontend Frameworks

The CORS configuration can sometimes be tricky to achieve, and hence developers serve both backend and frontend under the same domain in production.
To minimize this effort and provide flexibility to work with CORS, React, Nuxt, Express, etc. allow users to replicate the setup in development.

As this setup is done at the server end, whenever a cross-origin request is made to the server, we can use  middleware like http-proxy-middleware to proxy requests.
Furthermore, we can also redirect and change the path of the request by using options like pathRewrite.

Contentstack UI Extension SDK

To help tackle the CORS errors in our Extension SDK, we have used/allowed the following sandbox attributes in our UI extension:

  • allow-scripts: This flag re-enables an extension to run JavaScript in its sandbox
  • allow-popups: Use this flag to enable your extension to open pop-ups.
  • allow-popups-to-escape-sandbox: This flag allows the sandboxed document to open new windows without imposing any sandbox-specific restrictions on them.
  • For external hosting of extension, ‘allow-same-origin’ will be enabled.
  • Since an extension is run in a sandboxed iframe, it receives the origin null. Because of this reason, custom web fonts do not work as expected.
    To overcome this, you need to configure your servers to send the headers: Access-Control-Allow-Origin null or Access-Control-Allow-Origin

Refer to our Experience Extensions FAQs section to learn more about the most common questions related to Extension SDK.

Was this article helpful?

Thanks for your feedbackSmile-icon

On This Page

^