Security Risks of CORS

4 min readNov 16, 2019

Hey everyone.

As we see, these days webpages are full of animations, different font styles, GIF’s, images, videos etc. They even requests for and include different font styles and other scripts from any other website without user interaction. So what will happen if any bad guy in hoodie and green terminals hosts a malicious script on other-site.com to steal data from site.com? To prevents these kinds of “Cross” site attacks, SOP came into existence.

Same-origin Policy: SOP is a browser’s security mechanism which prevents one website to load scripts or request for other resources from another website/different origin.
Different origin ? When can we say that two URL’s are in same origin ?
If protocol, host and port are all same for two URL’s then we can say that both the URL’s are having same origin.
For example, let’s see if the following URLs are in same origin with http://domain.com

         URL             Result           Reason
http://domain.com/path    Yes     Protocol, host and port are same                     https://domain.com        No      Protocol is not same.
http://domain.com:8080    No      Port is not same.
http://a.domain.com       No      Host is not same.

Note: Internet Explorer doesn’t care about port into same-origin checks.

Okay, sounds great. But what if I, the developer/admin of my-site.com wants to access some resources from my-other-site.com on which i completely trusts? To solve this issue Cross-origin resource sharing was introduced. CORS allowed developers to share resources between the sites they want to.

Cross-origin resource sharing (CORS)

It is a browser’s mechanism which allows sharing of resources from different origins. So, basically you allow access to the websites you trust to share resource with, and when a website with another origin requests for a resource, the application sends an HTTP request with origin header. If the origin is trusted it sends back the requested resource with Access-Control-Allow-Origin andAccess-Control-Allow-Credentials header in response.

Origin header: Origin header contains the URL from where the request has originated.
Access-Control-Allow-Origin: This header is send back in the response from one website to a request originated from another website, telling the website that it is allowed to access the resource.
Access-Control-Allow-Credentials: If this header is set to true then only you can share cookies and other credentials with another website.

CORS Specification

> Multiple origins:
Access-Control-Allow-Origin: http://domain1.com http://domain2.com
However, no browser supports multiple origins.
> Wildcards (*):
Access-Control-Allow-Origin: *
Sadly, you can use only this wildcard, means you allow each and every website, you can’t use wildcards on any other way like https://*.website.com to allow all subdomains of your website.
For security measures it automatically disables the Allow-Credentials header when using a wildcard. You need to specify a domain if you want to allow credentials.

> Null origin:
Acess-Control-Allow-Origin: null

Exploiting CORS misconfiguration
1. Origin reflection : In some cases, web server generate Access-Control-Allow-Origin header based on the origin they recieved in the requests. Which means any site can access the resource. So if a attacker intentionally changes the origin header and gets back ACAO header in response with his website and credentials set to true then the attacker can use this misconfiguration to get any secret data by hosting a html page with simple script on his website.

2. Null origin : If a website allow null origin then also it is exploitable as any website can obtain null origin using a sandboxed iframe.
3. Pre-domain wildcard: If a non existing domain like somevictim.com allowed access then the attacker can register this domain and can steal your data.
4. Post-domain wildcard: If victim.com.attacker.com is allowed, then an attacker can simply set up a domain like this to steal your data.
5. Sub-domains allowed: If sub.victim.com is allowed, the also an attacker can exploit this if he finds an XSS vulnerability in subdomain.