What is Cross Origin Resource Sharing : Beginners Guide To CORS

​​​Cross-origin resource sharing (CORS) is a standard for accessing web resources on different domains. CORS allows web scripts to interact more openly with content outside of the original domain, leading to better integration between web services. A web page may freely embed cross-origin images, stylesheets, scripts, iframes, and videos. Certain "cross-domain" requests, notably Ajax requests, are forbidden by default by the same-origin security policy. CORS defines a way in which a browser and server can interact to determine whether or not it is safe to allow the cross-origin request. It allows for more freedom and functionality than purely same-origin requests, but is more secure than simply allowing all cross-origin requests.

As we know that the web browsers implement a security measure known as the same-origin policy to prevent websites from tampering with each other. The same-origin policy lets resources such as JavaScript interact with resources from the same domain, but not with resources from a different domain. This provides security for the user by preventing abuse, such as running a script that reads the password field on a secure website.

In cases where cross-domain scripting is desired, CORS allows web developers to work around the same-origin policy. The CORS standard describes new HTTP headers which provide browsers and servers a way to request remote URLs only when they have permission. Although some validation and authorization can be performed by the server, it is generally the browser's responsibility to support these headers and honor the restrictions they impose.

An example of a cross-origin request: A HTML page served from http://domain-a.com makes an src request for http://domain-b.com/image.jpg. Many pages on the web today load resources like CSS stylesheets, images, and scripts from separate domains, such as content delivery networks (CDNs).


 1. The browser sends the OPTIONS request with an Origin HTTP header. The value of this header is the domain that served the parent page. When a page from http://domain-a.com attempts to access a user's data in domain-b.com, the following request header would be sent to domain-b.com :

For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. For example, XMLHttpRequest and the Fetch API follow the same-origin policy. This means that a web application using those APIs can only request HTTP resources from the same domain the application was loaded from unless CORS headers are used.
     Origin: http://dmain-a.com
2. The server at dmoain-b.com will respond with an Access-Control-Allow-Origin header in its response indicating which origin sites are allowed. For example:
     Access-Control-Allow-Origin: http://dmain-a.com
If the server does not allow the cross-origin request then an error page will return. An Access-Control-Allow-Origin header with a wildcard that allows all domains:
     Access-Control-Allow-Origin: *
A wildcard same-origin policy is appropriate when a page or API response is considered completely public content and it is intended to be accessible to everyone, including any code on any site. For example, a freely-available web font on a public hosting service like Google Fonts. The value of "*" is special in that it does not allow requests to supply credentials, meaning HTTP authentication, client-side SSL certificates, nor does it allow cookies to be sent.

CORS Headers :

There are nine HTTP headers that are related to CORS but we will see only few of important of them :

Access-Control-Allow-Origin: This is a response header, as soon as a request is made to the server for exchanging data, the server responds with a header that tells the browser whether the origin of the request is listed inside the value of this response. If the header is not present or the response header does not contain the request origin inside the header, then the request is dropped and a security error is raised (as seen earlier in the last section), otherwise the request is processed.

Syntax:
 Access-Control-Allow-Origin: *
 Access-Control-Allow-Origin:
Example:
 Access-Control-Allow-Origin: http://dmain-a.com
Access-Control-Allow-Methods: This is another response header; the server responds with this header and instructs the browser to check for allowed HTTP methods mentioned inside it. If the server only allows GET and a POST request is initiated then it will be dropped if not mentioned in this list.

Syntax:
 Access-Control-Allow-Methods: GET, POST, PUT...
Origin: This is a request header which tells the server from which domain origin the request was attempted. The origin header is always sent alongside cross-domain requests.

Example :
 Origin: http://dmain-a.com

Pre-Flight Request :

A pre-flight request is just a normal HTTP request that happens before the actual cross-domain communication. When performing certain types of cross-domain Ajax requests, modern browsers that support CORS will insert an extra "preflight" request to determine whether they have permission to perform the action.

For example :
 OPTIONS /
 Host: domain-b.com
 Origin: http://dmian-a.com
If domain-b.com is willing to accept the action, it may respond with the following headers:
 Access-Control-Allow-Origin: http://domain-a.com
 Access-Control-Allow-Methods: GET, PUT, DELETE


Conclusion : 

The CORS mechanism supports secure cross-domain requests and data transfers between browsers and web servers. CORS makes it easier for service providers to distribute content to users while adding interoperability to online services.

Also Read About : Same-Origin-Policy here