Was this article helpful?
Thanks for your feedback
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.
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).
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.
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).
Let's discuss some of the best practices for avoiding CORS errors by using a Custom Field Extension in Contentstack.
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.
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:
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.
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.
To help tackle the CORS errors in our Extension SDK, we have used/allowed the following sandbox attributes in our UI extension:
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.
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 feedback