Think Outside the Scope: Advanced CORS Exploitation Techniques

May 14, 2019 · 7 min read

Hi everyone,

My name is Ayoub, I’m a security researcher from Morocco. In this article, I will be describing two different cases of how I was able to exploit a CORS misconfiguration: The first case based on an XSS, and requires thinking outside of the scope, and the second is based on an advanced CORS exploitation technique.

Note: Before You start reading this write-up, you will need to have a basic understanding of what CORS is and how to exploit misconfigurations. Here are some awesome posts to get you caught up:


Vulnerable Endpoint

About a year ago, I was hacking this private program, hosted by HackerOne. After playing with the Origin header in the HTTP request, then inspecting server response to check if they do domains whitelist check or not, I noticed that the application is blindly whitelisting only the subdomains, even non-existing ones.

For privacy reasons and the responsible disclosure policy, let’s assume that the web application is hosted in:

This CORS misconfiguration looks something like this:

HTTP Request:

GET /api/return HTTP/1.1
Connection: close

HTTP Response:

HTTP/1.1 200 OK
Access-control-allow-credentials: true

This API endpoint was returning the user’s private information, like full name, email address, ….

To abuse this misconfiguration so we can perform an attack, like leaking users’ private information, we need either to claim an abandoned subdomain (Subdomain Takeover), or find an XSS in one of the existing subdomains.

Think Outside The Scope

Finding an abandoned subdomain is not that trivial, so I decided to go for the second option, finding an XSS in one of the existing subdomains. However, the scope of this private program is limited to only:, Which means that finding an XSS in other subdomain is definitely out of the scope, but chaining this XSS with the CORS misconfiguration is somehow in the Scope. Right?

And, the fact that the other subdomains are out of scope, is the reason that made me more confident, that there is a big chance of finding an XSS on those subdomains since other hackers will not be testing them.

So, I start searching for this XSS, with a heart full of hope to find it, And In less than one hour, I found one in, using the following payload:

Time to create a nice Proof of Concept, and submit a report

Reproduce :

So to exploit this CORS Misconfiguration we just need to replace the XSS payload alert(document.domain), with the following code:

Like This :

And Voilà, we now have a nice PoC:


Now, What if I told you that you can still abuse this issue without the need of finding an XSS in any of the existing subdomains, or claiming an abandoned one.

That exactly what we will be discussing in the second case.


Vulnerable Endpoint

This time, I was working on the Ubnt Program, and especially the Application hosted in:

Following the same process, I identified the same CORS Misconfiguration, similar to the previous case, but this time the application fetches the user’s private information from a different location, An API hosted in:

This Application also blindly whitelist any subdomains, even non-existing ones.

And, As we discussed before, to abuse this CORS misconfiguration you will need, either claiming an abandoned subdomain, or finding an XSS in one of the existing subdomains.

And since this is a public program, with big scope (All the subdomains are in scope); there is a tiny chance of finding an XSS, not even mentioning a subdomain takeover vulnerability.

So, did we reached a dead end?

Advanced CORS Technique

Well, It turns out, that there is another way, But it requires a certain condition to work.

An interesting research done recently by Corben Leo can be found here. Showed that it’s possible to bypass some controls implemented incorrectly using special characters inside the domain name.

This research is based on the fact that browsers do not always validate domain names before making requests. Therefore, if some special characters are used, the browser may currently submit requests without previously verifying if the domain name is valid and existent.


The fully understand this issue, let’s try to open a URL with special characters like: http://asdf` Most browsers will validate the domain names before making any requests.

The domain, is used as a demo, because it’s has a wildcard DNS record






As you can see, Safari is an exception, it will actually send the request and try to load the page, unlike the other browsers.


And we can use all sorts of different characters, even unprintable ones:

Furthermore, another research done by Davide Danelon can be found here, showed that the other Subset of these special characters can also be used on other browsers.

From Davide Danelon research:

Now, we know all of this, how can we abuse this issue to perform an Advance CORS Exploitation Technique, for a nice demonstration, let’s go back the vulnerable web application on:

The new approach

In this case, the web application also accepts the following Origin *!

Not just the character “!” , but also the following ones:

And you should know by now that some browsers, such as Safari, accept URL with special characters, like:

So if we set up a domain: with a wildcard DNS record, allowing to point all the subdomains (* to, which will be hosting a script in a page like: that will simply send a cross-domain request with the subdomain name as the origin value to the vulnerable endpoint

Then somehow we forced an authenticated user to open the link:

Theoretically, we can exfiltrate this user’s private information, as a result.

Reproduce :

  1. First, set up a Domain with a wildcard DNS record pointing it to your box, in my case, I used GoDaddy to host my domain, with the following configuration:

2. Install NodeJS, create a new directory, and then save inside it the following file:


3. In the same directory, save the following:


4. Start the NodeJS server by running the following command:

5. Now, sign in to the application on:, and check that you can retrieve your account information from the endpoint:

6. Finally, open the link: In Safari Browser, And Voilà.

In my case I used the Safari browser in my iPhone as PoC, since I don’t have a Mac machine.



I’m sure that a lot of security researcher had already been in such situation, and you can find lots of report in HackerOne describing this type of CORS misconfiguration, but only a few were able to fully exploited it, due to lack of a PoC in their report.

That’s one of the reasons why I wanted to share my experience. also to highlight other techniques to exploit such vulnerability.

Finally, Always remember, Sometimes you just need to think outside the ̶B̶o̶x̶ Scope.

Thanks for reading. Feel free to follow me on Twitter

Happy Hunting.

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew


Written by


Sr. Security Engineer, Ethical Hacker, Bug Bounty Hunter At HackerOne, Synack Red Team, and BugCrowd. | Tweet @sandh0t

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade