What is CORS?
I’m glad you asked! It stands for Cross Origin Resource Sharing, and while you might think it helps protects your servers from attacks, it actually creates a vulnerability in your site.
Note that CORS is a web-specific feature, implemented by browsers. If you’re not making a request from a browser, none of this will apply.
By default, browsers implement a same-origin policy, (sometimes called a single-origin policy). What this does is disallow a website, script, or document from receiving a request for resources from another website. This is used to help protect the website that is being accessed for resources from attacks and exploitation. If another website can’t make requests to your site, it will be that much safer. And while you may not want malicious scripts accessing your server, you may run into a situation where you do need to access resources from different origins. For example, if you need to fetch some resources from an external API.
CORS is what allows access to your resources. And since you’re allowing outside access to your server, you’re going to want it to be done as securely as possible. It works by declaring, on the server side, what origins have access to the data. An origin being defined as the protocol , host , and port the request comes from, or is sent to, (everything in a URL before the route).
When the request is made to your server, it sends a header along with it, called Origin:. This contains the origin of the site making the request. Your server then returns a header to the site making the request, called Access-Control-Allow-Origin:. If the site making the request in Origin: is included in Access-Control-Allow-Origin:, then the site making the request is allowed to see the response. This allows you to make cross site requests, but only allow specific origins to see the data generated by those requests, keeping malicious scripts from seeing your private data. Note that you can set Access-Control-Allow-Origin: to *, and this will give any and all origins access to your resources.
This is what’s called a Simple request, but there are actually some slight variations to how a CORS request can be handled. A GET, POST, or HEAD request with default headers just submits the Simple request. However, if there are any other headers attached to a request, it will trigger a Preflight request. Instead of sending the full request right away, the browser will send an HTTP request with the OPTIONS method. When the server receives this, it will send back headers that determine wether the origin can receive resources BEFORE any meaningful data is sent to the server.
Along with Access-Control-Allow-Origin:, some typical headers sent back for ORIGIN requests are Access-Control-Allow-Credentials:, and Access-Control-Allow-Methods:. With these headers you can define wether you want the browser to send cookies or what type of requests are allowed(POST, PATCH, Etc.), and there are plenty of other headers to help control what information get passed around.
It’s worth noting that if using the Allow-Credentials header, you will have to specify a specific origin inAccess-Control-Allow-Origin:, as * will get rejected.
Also, If sending credentials, remember that you will also need to specify this in your request, as the browser will not send credentials automatically, even if the OPTIONS response allows them. Some examples of this are the credentials option in the Request() constructor of the fetch API, or the withCredentials method for an XMLHttpRequest.
There is certainly a lot of information and nuance to CORS, but hopefully this helps to put some of it in perspective. I highly recommend reading the documentation to get a more rounded understanding of what all CORS can do for you, and what precautions you should take when using it.
Resources:
