A little about CORS
A little info about Cross-Origin Resource Sharing
As I continue to work in this space I continue to come across things that I either haven't heard about or have heard, but don’t know that much about. So as in a way for me to learn, I write a post about it to help put the information down, which helps me remember. For this week, I’m writing about CORS or cross-origin resource sharing. I will talk about what it is, what are some of the other options, and a little about how it works. As always I will share the resources I used, so you can get really into them if you so choose.
As I start with most of my posts, I have to explain one thing in order to explain the main topic. In this case that is security. So as you probably know, or at least I assume you know if you are reading this, is that a lot of things are hosted on the internet. Everything from webpages to fonts to images. Some of these things are native to the server that the site you are looking at is hosted. and some are not. The ones that aren’t, are being pulled from a different server. There are two ways to handle these requests, Same-Origin and Cross-Origin.
SAME-ORIGIN POLICY
So everything in the same-origin policy, as the name might reveal, comes from the same origin, or in this case the same server. This is a very restrive way of handling data, but it helps mitigate attacks, by limiting attack vectors. There are three parts of an origin that have to match for same-origin, to allow sites to connect with each other protocol, host, and port number. If everything doesn't match, then access is restricted. The need for security is pretty obvious, but the same-origin policy is very restrictive.
CORS-CROSS-ORIGIN RESOURCE POLICY
That's where CORS comes in. It allows you to set what resources your site can access, things like stylesheets, fonts, or images. Browers for the purpose of security restrict cross-origin HTTP requests that were initiated from scripts. That means that XML requests and Fetch API follow the same-origin policy. The only way around that is if the other origins have the correct CORS headers, which I will get to shortly.
This is necessary because it allows sites to set who and how their assets can be accessed. Requests are made with traditional methods. Most sites will allow GET requests but probably won’t allow PATCH, PUT, or DELETE. CORS has its own list of headers that can be added to a request. They are:
Access-Control-Allow-OriginAccess-Control-Allow-CredentialsAccess-Control-Allow-HeadersAccess-Control-Allow-MethodsAccess-Control-Expose-HeadersAccess-Control-Max-AgeAccess-Control-Request-HeadersAccess-Control-Request-MethodOrigin
Instead of just blindly blocking some requests, a pre-flight request is initiated. These requests will trigger a pre-flight:
PUTDELETECONNECTOPTIONSTRACEPATCH
The purpose of the pre-flight is to check whether say a DELETE request is safe to process. If it is the request will go through, if not it will block the request.
CONCLUSION
Now there you have it. I hope this gave you a slightly better understanding of what CORS is and how sites protect themselves. Look into the resources and increase your knowledge a little more.
