CORS stands for Cross-Origin Resource Sharing. This simply means sharing of data across different domains.
Getting data from another domain to our domain is not a problem when you are running a script or some program on your server. That program can access data from any domain be it another or its own. You just have to have the proper authorization for it.
As written above CORS means sharing data across domains. This allows the servers to serv data to anyone they want as they want. Different web applications can use data from anywhere like if any delivery app wants to use maps for tracking the delivery persons, it can use Google maps for it. The developers wouldn’t need to develop their own maps for it.
A resource can be demanded from anywhere depending on the type of application you have and as you try to call an API which will give you the required resource, BAM!!!!!
Access to fetch at ‘https://another-site.com/’ from origin ‘https://example.com’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
You get this error in your browser console. It says here that you cannot access resources from another origin or domain. As a web developer, you might have come across this error.
I talked about accessing any resource from a program running on the server before but while doing the same from web application causes a problem.
Browsers worldwide have a security policy against open access to cross-domain resource sharing.
This restriction exists because requests made at other domains by your browser would carry along your cookies which often means you’d be logged in to the other site. So, without same-origin, any site could host JavaScript that called logout on stackoverflow.com for example, and it would log you out. Now imagine the complications when we talk about social networks, banking sites, etc.
The same-origin policy was invented because it prevents code from one website from accessing credential-restricted content on another site. Ajax requests are by default sent with any auth cookies granted by the target site.
For example, suppose I accidentally load http://evil.com/, which sends a request for http://mail.google.com/. If the SOP (same-origin policy) were not in place, and I was signed in to Gmail, the script at evil.com could see my inbox. If the site at evil.com wants to load mail.google.com without my cookies, it can just use a proxy server; the public contents of mail.google.com are not a secret (but the contents of mail.google.com when accessed with my cookies are a secret).
Sometimes, however, it’s not evil.com trying to peek into your inbox. Sometimes, it’s just a helpful website (say, http://goodsite.foo) trying to use a public API from another origin (say, http://api.example.com). The programmers who worked hard on api.example.com want all origins to access their site’s contents freely. In that case, the API server api.example.com can use CORS headers to allow goodsite.foo (or any other requesting origin) to access its API responses.
All CORS requests are API based. Any access to the resource by another domain has to be managed by the particular API which serves that resource.
Before getting to “api-headers” part, we should talk about what any browser does exactly –
4.1.1. Browser activity for Cross-Domain requests
Browser does a pre-flight request before your API call, means before any type (GET, PUT, POST or DELETE) of API call, browser does an OPTIONS request to the same API. So you need to implement OPTIONS request in addition with the type that you want for all the APIs that should be allowed for cross-domain.
4.1.2. Necessary API-Response-Headers
Browser expects a few headers in response to any API call and pre-flight (discussed above) of that API –
‘Access-Control-Allow-Origin’: ’your-domain.com’,
‘Access-Control-Allow-Credentials’: true,
‘Access-Control-Allow-Methods’: “POST, GET, DELETE, PUT”,
‘Access-Control-Allow-Headers’: “Content-Type,append,delete,entries,foreach,get,has,keys,set,values,Authorization”
The values for the above can be modified as per your discretion. If you want all domains to access your API, put ‘Access-Control-Allow-Origin’: ‘*’.
This is simple!!!. As I discussed above, any program running on a server can access any cross-domain API. You can use your server to get the resource. This can be done in two ways –
location /yourAPi {
proxy_pass cross-domain_API;
}
Note: not all server-creators support reverse proxy
This is another trouble that can haunt you as a developer if you’re using an iframe of a different domain on your website.
The resources that iframe can access from your website will be limited. You won’t be able to access parent window in DOM by using “window.parent.window.<anything>”.
Of-course there are ways to communicate and access parent through mutual agreement. For example: You can use something called postMessage() to send request to the parent window by using “window.parent.window.postMessage()”. This is an exception allowed for developers to communicate in cross-origin DOMs.
You can find details of using this from https://medium.com/javascript-in-plain-english/javascript-and-window-postmessage-a60c8f6adea9.
Thank you for reading and happy coding!!!
See us at https://fibotalk.com/