What are Cross Origin Resource Sharing (CORS) Headers?

What are CORS headers?

Introduction

CORS headers, or “Cross Origin Resource Sharing” headers, are an important feature of HTTP that ensures that only content permitted by other websites/servers to be loaded on your page will actually be used. Note: this is not a mechanism to prevent you from accessing any content; you can visit a URL directly (when you see a “CORS” header that disallows 3rd party websites from using their CSS/JS/other resources) to view the associated file/resource.

Having said that, one crucial thing to remember is that CORS headers cannot prevent content from loading from the same origin. That is, if you request the page “bunny.net,” and “bunny.net/css/main.css” is requested from that page, no header exists that can stop the request or notify any browser that the request should not be permitted.

How Cross Origin Resource Sharing(CORS) works

Suppose that we are looking to fetch weather information from a publicly accessible API. Using the following JS, we can initiate a GET request from our imaginary website to the imaginary “weather” endpoint:

$.ajax({ 
		url: “http://weather-api-website.bunny.net/api/weather”, 
		type: "GET", 
		dataType: "json", 
		success: function (data) {
				alert(“It is currently ” + data.temperature + “ degrees outside!”); 
		} 
		error: function (xhr, opt, err) {
				alert(“Failed to retrieve data.”);
		}
});

For the sake of the example, our “imaginary” website will be “test.b-cdn.net.”

When we load our “weather” page on “test.b-cdn.net,” your browser will check for the Access-Control-Allow-Origin header. If the weather API returned a Access-Control-Allow-Origin header value of * or the hostname of our page, we’d be in good shape.

However, if the server responded with Access-Control-Allow-Origin: http://new-weather.b-cdn.net, we’d receive an HTTP error stating that our website has not been allowed to make a request. In essence, our XHR (AJAX) request to “http://weather-api-website.bunny.net/api/weather” would fail and no data will be returned. In the context of our JS code, we would not know that the request has failed due to a cross-origin error; such errors are only visible through a browser’s console. On top of this, the error will be treated similarly to other HTTP errors (example: 403 Unauthorized, etc.) and it is the responsibility of the person programming the page to ensure that external APIs/sites allow for him/her to use their resources.

NOTE: Please understand that this scenario is highly unlikely; publicly accessible APIs will almost always have a wildcard * set for allowable origins. This ensures that CORS is effectively ignored for a resource designated as public — the scenario is purely used as an example.

With that said, as mentioned above, CORS does not protect against CSRF or unwanted users. CORS headers are ignored if you simply copy the resource URL and visit it directly; furthermore, there are a small number of services that allow you to “bypass” CORS through proxies that strip the header. This effectively nullifies any potential for use in “cross site forgery (CSRF)” protections.

Conclusion

CORS headers, or “Cross Origin Resource Sharing” are exactly what they imply: they are designed to allow websites, or servers, to share resources with other websites. Whether they are set to allow all “3rd party” requests (i.e. requests from any origin) to only specific websites, they ensure that websites cannot simply access restricted resources from external sources (origins).