These days, a web page commonly loads images, stylesheets, scripts, etc. from other domains. Although, a few years ago due to security reasons, web fonts and AJAX (XML Http Requests) were normally restricted to the same-origin policy which restricted their use between domains. Now however, with the use of CORS, the browser and server can communicate to determine whether it is safe to allow a cross-origin request.
Why Use CORS?
CORS was implemented due to the restrictions revolving around the same-origin policy. This policy limited certain resources to interact only with resources from the parent domain. This came with good reason as AJAX requests are able to perform advanced requests such as POST, PUT, DELETE, etc. which could put a website’s security at risk. Therefore, the same-origin policy increased web security and helped prevent user abuse.
However, in some cases, it is quite beneficial to enable cross-origin resource sharing as it allows for additional freedom and functionality for websites. This is true in many cases these days for web fonts and icons which are often requested from another domain. In this case, with the use of HTTP headers, CORS enables the browser to manage cross-domain content by either allowing or denying it based on the configured security settings.
HTTP Request Headers
When a domain is requesting to interact with a resource on another domain, request headers are added from the first domain in order to use the cross-origin resource sharing feature. These are the HTTP request headers that may be associated with the requesting domain.
HTTP Response Headers
The domain who’s resources are being requested can respond to the first domain with the following HTTP response headers based on what configuration options are set.
Simple CORS Example
Here is a simple CORS example of when a browser requests a resource from another domain. Let’s say DomainX makes a request to DomainY for a particular resource. CORS uses HTTP headers to determine whether or not DomainX should have access to that resource. The browser automatically sends a request header to DomainY with
DomainY receives that request and will respond back with either:
- Access-Control-Allow-Origin: http://domainx.com
- Access-Control-Allow-Origin: * (meaning all domains are allowed)
- An error if the cross-origin requests are not allowed
Preflight CORS Example
When certain, more complicated, types of requests are performed, the browser will insert additional preflight requests to validate whether they have the appropriate permissions to perform the action. A request is preflighted if any of the following conditions are met:
- It uses an HTTP method other than GET or POST
- Custom headers are set
- The request body has a MIME type other than text/plain
Here is an example of a preflight request:
Origin: http://domainx.com Access-Control-Request-Method: POST Access-Control-Request-Headers: X-Custom-Header
If DomainY.com is willing to accept the action, it may respond with the following headers:
Access-Control-Allow-Origin: http://domainx.com Access-Control-Allow-Methods: GET, POST Access-Control-Allow-Headers: X-Custom-Header
The same-origin policy does not allow for websites to communicate with each other’s resources which can greatly limit a site’s functionality. For this reason, CORS is a great feature for minimizing the amount of security risks involved with web script sharing, while being able to utilize resources outside of the origin domain.
Having the ability to select which domains are allowed to access certain resources also gives added granularity to the resource sharing capability. When configured properly, CORS can easily integrate with other web services while keeping your website and users secure.