Complete Guide to Cross-Origin Resource Sharing (CORS)

In an effort to keep a website and users of said website secure from any security risks involved with sharing resources like JavaScript and fonts across multiple domains, the use of CORS is recommended, but what is CORS?

What is CORS?

CORS, also known as Cross-Origin Resource Sharing, allows resources such as JavaScript and web fonts to be loaded from different domains than the origin parent domain, or in simpler terms, the site you’re visiting.

These days, it’s really common to use this, but a few years ago due to security reasons, fonts, AJAX/XML HTTP Requests were traditionally restricted to the same-origin policy, prohibiting their use between domains. This is no more, however, and with the use of CORS, the browser and origin-server can communicate with each other and determine whether it’s safe to allow a CORS request.

Why use CORS?

CORS was implemented due to the restrictions we previously mentioned. This policy limited certain resources to interact with only the resources from the parent domain. This came with good reason since AJAX requests were able to perform advanced functions such as POST, PUT, DELETE, and more, and this jeopardized the security of a website. Therefore, the same-origin policy increased website security and helps prevent abuse.

However, in some cases, it’s beneficial to enable CORS as it allows for additional freedom and functionality for websites. This is true in cases where websites and icons are often requested from a different domain. In cases like these, with the use of HTTPS Headers, CORS enables the browser to manage the cross-domain content by either allowing or denying it based on the security settings.

HTTP Request Headers Used in CORS

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.

Origin
Access-Control-Request-Method
Access-Control-Request-Headers

HTTP Response Headers Used in CORS

The domain whose resources are being requested can respond to the first domain with the following HTTP response headers based on what configuration options are set.

Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Expose-Headers
Access-Control-Max-Age
Access-Control-Allow-Methods
Access-Control-Allow-Headers

Simple CORS example

Here is an example of CORS when a browser requests a resource from another domain. Let’s say google1.com makes a request to google2.com for a particular resource. CORS uses HTTP Headers to determine whether or not google1.com should have access to those resources. The browser automatically sends a request header to google2.com with:

Origin: http://google1.com

Google2.com 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

Example of CORS In Preflight

When specific and more complex requests are performed, the browser will insert additional preflight requests to validate whether they have the appropriate permissions to perform this action. A request is preflighted if any of the following conditions are met:

1. It uses an HTTP method other than GET or POST.
2. Custom headers are set.
3. The request has a MIME Type other than text/plain.

Here is an example of a preflight request:

Origin: http://google1.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-Custom-Header

If google2.com is willing to accept the action, it may respond with the following headers:

Access-Control-Allow-Origin: http://google1.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: X-Custom-Header

CORS Browser Support

CORS is supported by all major browsers. If your browser doesn’t support it, you should upgrade your browser.

• Blink- and Chromium-based browsers (Chrome 28+, Opera 15+, Amazon Silk, Android’s 4.4+ WebView, and Qt’s WebEngine)
• Gecko 1.9.1 (Firefox 3.5, SeaMonkey 2.0) and above.
• MSHTML/Trident 6.0 (Internet Explorer 10) has native support.
• MSHTML/Trident 4.0 & 5.0 (Internet Explorer 8 & 9) provide partial support via the XDomainRequest object.
• Presto-based browsers (Opera) implement CORS as of Opera 12.00 and Opera Mobile 12, but not Opera Mini.
• WebKit (Initial revision uncertain, Safari 4 and above, Google Chrome 3 and above, possibly earlier).
• Microsoft Edge All versions.

Spotting CORS Errors

You will more than likely notice there is an issue related to CORS on your site if certain fonts or assets aren’t loading properly. If you’re using a CDN, this issue is likely to occur whenever you decided to disable the CORS option in your Zone File settings. However, if you notice something isn’t rendering properly on your site, you can use the Google Chrome DevTools to help troubleshoot the problem.

Once you open the DevTools, navigate to the Console panel. You might see other warnings and errors there, but what you will be looking for is something similar to the text in the image below:

This error is saying the fonts located at the origin are blocking the origin (i.e. google.com) due to CORS. Therefore, since the origin isn’t allowed access, the fonts can’t be pulled from the origin to the CDN.

jQuery with CORS

Partially due to the ability to perform advanced requests, cross-domain AJAX requests are forbidden by default. With the use of CORS, however, you have the option to better define which methods are enabled. This helps increase website security while having the ability to use features that are otherwise inaccessible.

Font Awesome CDN

Having CORS enabled is required to properly display Font Awesome icons when a CDN is implemented. If CORS is not enabled, the Font Awesome icons will not work and will look similar to the image below:

Enabling CORS on the Origin Server

If you want to handle CORS settings server-side, you have the option of configuring CORS on the origin server. To enable CORS for static resources, such as CSS, fonts, JavaScript, and images, add the following code to your server using your .htaccess file:

Apache

<IfModule mod_headers.c>
    <FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css|css|js|gif|png|jpe?g|svg|svgz|ico|webp)$">
        Header set Access-Control-Allow-Origin "*"
    </FilesMatch>
</IfModule>

LiteSpeed Server

# Images and General graphics

<FilesMatch "\.(gif|png|jpe?g|svg|svgz|ico|webp)$">
SetEnvIf Origin ":" IS_CORS
Header set Access-Control-Allow-Origin "*" env=IS_CORS
# Webfons

<FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css|css|woff2)$">
Header set Access-Control-Allow-Origin "*"

Nginx

location ~ \.(ttf|ttc|otf|eot|woff|font.css|css|js|gif|png|jpe?g|svg|svgz|ico|webp)$ {
    add_header Access-Control-Allow-Origin "*";
}

Quick CORS Security Notes

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 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 access to which resources also gives you granularity to the resource sharing capability. When configured properly, CORS can easily integrate with other web services while keeping your website and customers secure.