Cross-Origin Resource Sharing
An introduction to CORS
Same-Origin-Policy
In the early days of the internet, the only available content consisted of plain text and plain files which could only be accessed via email or special message boards. When Sir Tim Berners-Lee developed the World Wide Web in 1989, he extended the availability of content to also include layouts, text decoration, media embedment and more in a Hyper Text Markup Language(HTML). Web browsers began to explode in popularity, each eager to render HTML documents and expand the availability of content. In the mid ’90s, Netscape introduced a new feature to their web browser that made it possible for online entities to interact with all properties of an HTML document — the Document Object Model. Netscape engineers needed to ensure that their new feature did not leave web pages vulnerable to malicious attacks, so all DOMs had to adhere to a Same-Origin-Policy(SOP), whereby the border for each resource loaded by the browser is defined by a string, known as the origin, and only resources that share the same origin can reach one another’s attributes.¹
To overcome these limitations, developers had to get creative and began to set up proxies and wrap resources in padded JSON files delivered via callback in order to mimic the same origins and allow for resource sharing. Then, a new standard was enacted — Cross-Origin Resource Sharing.
Cross-Origin Resource Sharing
CORS requests are broken into two categories: simple requests and pre-flight requests. Requests come with several headers that contain information about the request which are parsed and used to determine if the request will be allowed or denied. For simple GET/POST/HEAD requests, the client sends a request with its origin, request method and request headers. The site being queried will respond with its own information on the response: Access-Allow-Origin(what origin is valid — either one origin or * denoting any), Access-Control-Allow-Methods(what requests are valid), Access-Control-Allow-Headers, Access-Control-Max-Age(how long the response is valid) and Access-Control-Allow-Credentials(auth/cookies). Simple requests are very limited and nearly all real-world API calls are not considered simple requests.²
In order to prevent the need to manually write out explicit headers for each and every request made by the client, there exists CORS middleware to automate the process.
CORS middleware can be configured to be as strict or lenient as you wish. The headers can be configured to accept only specific origins and methods or to accept any origin and method.
Conclusion
The origin of CORS policy stems from the need to protect shared resources on browsers and ensure user security. After trying many approaches, the standard adopted was to do this by attaching headers to the request from clients and responses back which enumerate the exact boundaries of resources that can be attained. CORS middleware is available to make the process more streamlined.