CORS(Cross Origin Resource Sharing): Security Protocol

As discussed in topic SOP, it is an important security concept implemented to prevent JavaScript code from making request against a different origin than the one from which it was served.

Although the Same Origin Policy is effective in preventing, but it also prevents legitimate interaction between server and clients of a known and trusted origin.

Cross-Origin Resource Sharing(CORS) is a technique for relaxing the same-origin policy, allowing JavaScript on a web page to take a REST API served from different origin.

CORS allows cross domain HTTP exchange of data, means a page running at origin X can send and receive data from server at origin B, it is abundantly use in web application where document, web fonts and CSS are loaded from different origin.

CORS works by adding new HTTP header that allows web server to speak with a list of whitelisted domain(Trusted) that are allowed to connect and interact with server. Here browser reads the header and process accordingly so we can say this thing is browser enforced.

                                                      Source : wikipedia / cors flow diagram

Example:(Reference: https://en.wikipedia.org/wiki/Cross-origin_resource_sharing)

When cross origin request is made under CORS:

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://www.example.com attempts to access a user's data in service.example.com, the following request header would be sent to service.example.com:

Origin: http://www.example.com

2.The server at service.example.com may respond with:

An  Access-Control-Allow-Origin header in its response indicating which origin sites are allowed. For example:

  Access-Control-Allow-Origin: http://www.example.com

 An error page if the server does not allow the cross-origin request

 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.

A wildcard same-origin policy is also widely and appropriately used in the object-capability model, where pages have unguessable URLs and are meant to be accessible to anyone who knows the secret.

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.^[10]

Note that in the CORS architecture, the ACAO header is being set by the external web service (service.example.com), not the original web application server (www.example.com). CORS allows the external web service to authorize the web application to use its services and does not control external services accessed by the web application. For the latter, Content Security Policy should be used (connect-src directive)...

CORS Header:

Based on Response Header:

1. Access Control Allow Origin
2. Access Control Allow Methods               
3. Access Control Allow Credential
4. Access Control Allow Header

Based on Request Header:

1. Origin
2. Access Control Request Method
3. Access Control Request Headers