Although it is hard to notice, the webpages you visit regularly always request to load assets such as fonts, images and other resources from various places on the internet. And if the requests made are left unchecked, they compromise the safety and security of your browser. To mitigate these risks, the same-origin policy was established. This is a security protocol that ensures the documents hosted on a given server can only interact with other resources on the same server. Although this security protocol lowers web-system vulnerabilities, it is too restrictive, in that, it doesn’t allow sharing of resources between documents from different domains. However, CORS (Cross-Origin Sharing) has made this possible.
What is CORS?
CORS is a technique that permits resource sharing between scripts running on a browser client and resources from a different origin. Cross-Origin Resources Sharing uses additional HTTP headers to instruct the browser to allow a web application running at one domain to access specific resources from a server at a different origin. A few years ago, AJAX requests and web fonts resource sharing were restricted by the same-origin policy. However, today, developers can use CORS to facilitate cross-domain communication from the browser. The CORS protocol supports cross-origin data transfers and requests between web servers and browsers. CORS determines whether origin requests are made or not. And before we go further, let’s look at the two different request types.
1. Simple Request
This request type contains information that responds to the call on the use of HEAD, GET and POST methods in client CORS request. Simple requests are characterized as such since they can be made from a browser without using CORS.
An Example of Simple CORS
Let’s say Domain A makes a request to Domain B for a particular resource. CORS utilizes HTTP headers to determine whether or not the Domain A is allowed to access a specific resource. Then, a request header is sent automatically by the browser to Domain B with; origin: http://domainA.com
Upon receiving that request, Domain B will respond with:
- Access-Control-Allow-Origin: http://domainA.com
- Access-Control-Allow-Origin: * (meaning all domains are allowed)
- An error which shows that the cross-origin requests are not permitted.
2. Preflighted Requests
When more sophisticated requests are made, they cease to be a simple request, and the browser inserts what is known as preflight request to validate whether the client is permitted to perform the specified action. A request is said to be preflighted if it meets the following conditions:
- It utilizes an HTTP method atop POST or GET
- It comes with custom headers
- Its body features a MIME type other than text/plain
An example of a preflight CORS request:
Origin: http:// domainA.com Access-Control-Request-Method: POST Access-Control-Request-Headers: X-Custom-Header
The following will be the header responses if Domain B is willing to accept the action:
Access-Control-Allow-Origin: http://domainA.com Access-Control-Allow-Methods: GET, POST Access-Control-Allow-Headers: A-Custom-Header
Most modern browsers support CORS. Therefore, if your current browser doesn’t support CORS, most probably you are using an older version. You need to upgrade to the latest version or install another browser that supports CORS. For instance, Internet Explorer was partially supporting CORS until they released IE version 11. Other browsers that support CORS include:
- Opera 12+
- Chrome 3+
- Safari 4+
- Firefox 3.5+
What is CORS in a Web API?
Web API also provides excellent support for CORS. However, you need to enable CORS on the Web API server for you to make any requests. Enabling support for CORS can be done on three levels:
- Action Level
- Controller Level a
- Global Level
It is important to note that CORs support can only be enabled once you create a Web API project.