Skip to main content

CORS Best Practices

Cross Origin Resource Sharing (CORS) best practices

Free for all
A common example is if you own a website that displays content for the public, that is not behind paywalls, or requiring authentication or authorization – you should be able to set Access-Control-Allow-Origin: * to its resources.

The * value is a good choice in cases when:

No authentication or authorization is required
The resource should be accessible to a wide range of users without restrictions
The origins & clients that will access the resource is of great variety, you don’t have knowledge of it or you simply don’t care
A dangerous prospect of such configuration is when it comes to content served on private networks (i.e. behind firewall or VPN). When you are connected via a VPN, you have access to the files on the company’s network:

Oversimplification of VPNs
Now, if an attacker hosts as website dangerous.com, which contains a link to a file within the VPN, they can (in theory) create a script on their website that can access that file:

File leak
While such an attack is hard and requires a lot of knowledge about the VPN and the files stored within it, it is a potential attack vector that we must be aware of.

Keeping it in the family
Continuing with the example from above, imagine we want to implement analytics for our website. We would like our users' browsers to send us data about the experience and behavior of our users on our website.

A common way to do this is to send that data periodically using asynchronous requests using JavaScript in the browser. On the backend we have a simple API that takes these requests from our users' browsers and stores the data on the backend for further processing.

In such cases, our API is public, but we don’t want any website to send data to our analytics API. In fact, we are interested only in requests that originate from browsers that have our website rendered – that is all.


In such cases, we want our API to set the Access-Control-Allow-Origin header to our website’s URL. That will make sure browsers never send requests to our API from other pages.

If users or other websites try to cram data in our analytics API, the Access-Control-Allow-Origin headers set on the resources of our API won’t let the request to go through:


NULL origins
Another interesting case are null origins. They occur when a resource is accessed by a browser that renders a local file. For example, requests coming from some JavaScript running in a static file on your local machine have the Origin header set to null.

In such cases, if our servers do now allow access to resources for the null origin, then it can be a hindrance to the developer productivity. Allowing the null origin within your CORS policy has to be deliberately done, and only if the users of your website / product are developers.

Skip cookies, if you can
As we saw before with the Access-Control-Allow-Credentials, cookies are not enabled by default. To allow cross-origin sending cookies, it as easy as returning Access-Control-Allow-Credentials: true. This header will tell browsers that they are allowed to send credentials (i.e. cookies) in cross-origin requests.

Allowing and acepting cross-origin cookies can be tricky. You could expose yourself to potential attack vectors, so enable them only when absolutely neccessary.

Cross-origin cookies work best in situations when you know exactly which clients will be accessing your server. That is why the CORS semantics do not allow us to set Access-Control-Allow-Origin: * when cross-origin credentials are allowed.

While the Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true combination is technically allowed, it’s a anti-pattern and should absolutely be avoided.

If you would like your servers to be accessed by different clients and origins, you should probably look into building an API (with token-based authentication) instead of using cookies. But if going down the API path is not an option, then make sure you implement cross-site request forgery (CSRF) protection.

Comments

Popular posts from this blog

How the Python import system works

How the Python import system works From:  https://tenthousandmeters.com/blog/python-behind-the-scenes-11-how-the-python-import-system-works/ If you ask me to name the most misunderstood aspect of Python, I will answer without a second thought: the Python import system. Just remember how many times you used relative imports and got something like  ImportError: attempted relative import with no known parent package ; or tried to figure out how to structure a project so that all the imports work correctly; or hacked  sys.path  when you couldn't find a better solution. Every Python programmer experienced something like this, and popular StackOverflow questions, such us  Importing files from different folder  (1822 votes),  Relative imports in Python 3  (1064 votes) and  Relative imports for the billionth time  (993 votes), are a good indicator of that. The Python import system doesn't just seem complicated – it is complicated. So even though the  documentation  is really good, it d

On working remote

The last company I worked for, did have an office space, but the code was all on Github, infra on AWS, we tracked issues over Asana and more or less each person had at least one project they could call "their own" (I had a bunch of them ;-)). This worked pretty well. And it gave me a feeling that working remote would not be very different from this. So when we started working on our own startup, we started with working from our homes. It looked great at first. I could now spend more time with Mom and could work at leisure. However, it is not as good as it looks like. At times it just feels you are busy without business, that you had been working, yet didn't achieve much. If you are evaluating working from home and are not sure of how to start, or you already do (then please review and add your views in comments) and feel like you were better off in the office, do read on. Remote work is great. But a physical office is better. So if you can, find yourself a co-working s

Todo lists are overrated

My tasks come from a variety of sources: 1) Tasks from emails  2) Meeting notes with details of people who participated  3) Project related tasks that can have a long format and can be tagged/ delegated  4) Scratchpad for unrefined ideas  5) Detailed documentation for completed technical tasks / ideas  6) FIFO list of high priority small daily tasks No one app has been able to map all the requirements above, and I have tried a lot of them! In my lifetime I’ve tried a dozen todo apps. In the beginning they all seem different, novel and special. Slick UI, shortcuts, tags, subtasks, the list goes on and on. But all our stories were the same: I start using the new app, then after awhile I stop using it. Up until the last week I thought the problem was in myself (you probably think so too). After all, David Allen seems to have figured this shit out. Also there are people leaving long 5 star reviews on every major todo list app, they discuss them on forums, recommend them to friends. But the