Understanding the CORS Policy

I really wondered what CORS is and why CORS really should be configured the right way. Until now, CORS was like a necessary headache, which wasn’t really on my agenda while programming stuff for the web. This had been the reason because i also really did not understand a thing from it or why it was even there. Therefore, the way to go for me was just white-listing everything on my API Server to avoid any ugly errors in the JavaScript Console. This did fix the issue, but left me with a big question mark in my brain, why the heck CORS is even a thing.

CSRF

Ya know CSRF? Let me explain. Whenever you browse to your banking site and log in with your credentials, your browser is – like any other web application – sending the login data to a server. That can be the webserver itself (the easiest way possible, like in a small PHP environment) or (when it gets a bit more complex) to another API server, like api.super-secure-banking.cc while you are really browsing on www.super-secure-banking.cc

But why does this make a difference at all? And who really cares? Let me tell you: Your browser cares. Whenever you reach a URL on the internet, the browser loves content and data directly served from the original domain and gets pretty allergic when it comes to loading or sending stuff to sites which have a different domain name than the original site. And this is where CSRF comes into play, because that browser behavior stops something big.

Source: https://docs.openfaas.com/reference/cors/

As you can see in the picture, the scam site also asks for your banking credentials, and even looks like the original site. So if CORS is disabled, the scammy site just tells the user to login to the API of the banking service, get a authentication token – or so – and then free-willingly hands it out to the scam site which then has the full power over your banking account. This is rather bad and is calles “Cross Site Request Forgery”. Exactly at this point are coming good CORS-policies into play.

Allow-Origin

The API Server itself can not prevent really WHO is gonna carry the data boats to its ip-address. Wether it is my ping-command, my development environment or your scammy banking site, you all have different IPs and different locations from where you are trying to do your banking. So API-Side filtering will not work with IP.

The approach CORS does is that the responsibility of blocking content lies in the client’s browser. By doing so, the API Server can define from which locations (=domains) its letting doing requests from. So the browser can tell if a source of data is ok by comparing the URL with the Access-Control-Allow-Origin – Header sent from the API Server.

Of course this does not stop the issue of phishing, scarping other peoples sensitive data while looking out

Conclusion

That was a high-level introduction into the world of CORS. You can go in very much detail in this topic by investigating the possible Headers which an API Server can send.

Of course, feel free to share and comment this post, you are really therefore boosting my SEO appearance.

You can read more about this topic at https://enable-cors.org.


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *