CORS in Easy Words -- How to deal with CORS?
CORS errors are as dreadful as a SAARS infection to the website. We dread it. We dread what we don’t understand.
If you want the long, in-detail read, these guys explain it better than I can:
In easy words:
Due to some “security stuff” modern web browsers(specifically XHR and fetch ) are enforcing a security standard called Same-Origin policy.
Browsers are also implementing a standard called CORS for developers to be able to work with multiple origins when this is the case.
(It works with the help of HTTP headers. Headers are metadata “server” attaches to the response, to allow the browser to understand the data it receives.)
The enforcing bit:
Browsers will block access to all resources from a different origin, than the one it has asked for.
If a website on `xyz.in` references a font from `abc.com/abc.ttf`, browser will not load `abc.ttf` and show an error.
The implementing bit:
CORS uses HTTP headers. If you can configure the web-server on which your static website lives, you can set some headers to tell browser explicitly which resources are allowed to load from outside.
CORS is our friend:
You might think all of this is something that we were doing “just fine” without, but it is here to save some serious tushie. This is our chance of fighting the notorious XSS/CSRF attacks that keep happening all the time.
After this browsers are forcing you to tell them what origin is legal and what is not.
Too much info! Just tell me where to set the damn header:
Right! Here is the stuff.
Most of us are just confused because by definition there are multiple servers involved. And by the virtue of available (over-)guidance it is hard to pick which or our servers we want to apply those damned headers to.
Here: It is the server which serves the website. The server on which your index.html lives.
You set CORS headers from the web server serving your web pages. Once again… set the CORS headers that is closest to the browser. Once again… CORS headers are set by the server which contains your index.htm or index.php
Can we be clearer than this?
Yeah! Example:
CORS errors have been a pain in our deployments with an OTT Client, mastermentors.in (visit them right now and you’ll get a free cookie). We serve videos through a highly available CDN infrastructure (AWS Cloudfront) and the site is hosted on Firebase hosting.
This could very well be apache / nginx servers on any AWS EC2 Instance as well. Lets just stick with what we have for the time being.
For setting headers in apache2, use:
For setting headers with NGINX, use:
Our use case was Firebase, something for which tutorials are more sparse. Found this piece of documentation after X hours of searching. Take their example through a code-formatter and the scene is a little clearer.
So for now, we set Allow-Access-Origin for our .m3u8 files to allow from our specific cloudfront server. And that is how we dealt with it.
At Cookytech we design and we develop. If you are facing CORS issues and want us to take a look at it. Or you have a bigger issue / project and want people with a sense of responsibility on it, get in touch.
