Cross-origin resource sharing is a technique that enables the sharing of resources between two different origins on the web. This means that if origin A and origin B both use CORS, then a request from Origin A to fetch a resource from Origin B will not be blocked by the browser’s same-origin policy. The main idea behind this technique is to allow for better integration of third party resources with web apps in both browsers and web servers.
CORS has been around since 2009, but it remains poorly understood – even among many developers who should know about it already! Hopefully this article will help clarify some misconceptions about CORS and how it can benefit your website or app.
CORS is required when a script or iFrame element makes a cross-origin request. CORS is needed whenever a script makes a cross-domain request. An AJAX method, for example, which executes after the page has loaded and makes a resource request from another domain would be prohibited. It’s worth noting that CORS overrides the browser default setting, allowing the request to pass.
One misconception I’ve seen is that cross-origin requests are a security risk. The same-origin policy was put in place to prevent scripts from third party pages from performing actions on your current page, because the script could be doing something malicious.
In order for a browser to allow cross-origin requests, it must first send an extra request that contains additional information about the currently authenticated user as well as some other fairly technical stuff. This means that for every cross-origin request made to your website, the browser builds up all this extra information and transmits it automatically!
If you’re still concerned about this “extra data” being transmitted back to the origin of the resource, you can simply use CORS preflights instead–more on that later.
Another misconception is that without using preflighted requests, the browser allows any origin to access a resource on your website without permission. But if you dig deeper into how CORS actually works , you’ll see that this isn’t true either.
Not only do browsers send an OPTIONS request for cross-origin requests, but they must receive a specific response from the destination before any other requests can be sent. This means that in order for a cross-origin request to succeed, both the server and client (that’s us!) must agree upon it!
How CORS benefits your website or app
First things first: when you make a request to another domain, whether it’s for an image or CSS file, browser will block it by default. This is the same-origin policy in action; it prevents scripts from third party pages from performing actions on your current page because they could be doing something malicious.
CORS enables cross-origin requests through additional information that gets automatically transmitted with each request (hint: this “extra data” is called preflighted requests). You don’t have to configure anything special for CORS to work – your website already has everything it needs! There are currently three different ways of handling CORS requests according to the W3C Specification .
