Cross Origin Resource Sharing (CORS) is an important concept in modern webapplication security. We will try to explain what it is.
3 min read
By Robert Larsen
December 11, 2018
To understand CORS, we also have to understand the same-origin policy. The same-origin policy states that content retrieved from different origins are isolated from eachother. That is, if a webpage is retrieved from origin X it can interact with other resources on origin X only. Most browsers determine that two resources have the same origin if they have identical protocol, host and port. Internet Explorer is an exception, as it excludes the port from the same-origin check.
But, what if we know what we are doing and intentionally want to make requests between these two origins possible, in a secure and controlled manner? This is where Cross Origin Resource Sharing (CORS) comes in. In its simplest form, it allows servers to specifiy which origins that they will allow access to its resources.
The CORS-standard supports the following HTTP-headers:
We will not explain each here, but instead focus on the first one,
Allow-Origin. To allow every origin access, the server can use a wildcard, and return the following header:
Access-Control-Allow-Origin: *. This wildcard should only be used for a public, open API. If the server hosts an API that is supposed to be private, it should instead specify an allowed domain, or a comma separated list of domains, like
Access-Control-Allow-Origin: https://my-site.com, https://my-site2.com There are different solutions available for setting these headers. They can be set in the configuration of the webserver or they can be set on the endpoints in your application.
If you develop webapplications, you might have seen this message in your console when you try to make a request somewhere:
Failed to load <some URL>: No 'Access-Control-Allow-Origin' header is present on the requested resource. This is the same-origin policy in practice. As the message explains, the API is not sending the
Allow-Origin-header to allow access to the origin that you make the request from. If you or someone you know control the API it is easy, as you can configure the header yourself. If you do not control the API you should try to determine why the API does not send the header. Is the API not supposed to be requested by external consumers? Maybe you have to provide some authorization tokens?
In this post we have only scratched the surface of CORS. If you are interested in learning more you might enjoy looking into the referenced articles.