Hands-on documentation of Cross Origin — CORS and CSRF exploitation across two vulnerable applications, bWAPP for CORS misconfiguration and VulnBank for CSRF. What works, what does not, and why.

Cross Origin Attacks

An origin is the combination of a protocol, hostname and port number (an image attached below). Cross origin attacks happen when browsers do not use secure header attributes to prevent one origin from accessing the resources or another origin.

CORS vs CSRF — What's the Difference?

These two vulnerabilities are closely related and often confused, but they target different things. Understanding the distinction is critical before testing. CORS( Cross Origin Resources Sharing) abuses permissive cross-origin response headers and the goal is to read sensitive cross origin responses while CSRF (Cross Site Request Forgery) is when an attacker tricks a victim to a site where the user is already has an active authenticated session to trigger state-changing actions on behalf of victim.

CORS Exploitation on bWAPP

bWAPP (Buggy Web Application) is a deliberately vulnerable PHP app used for web security practice. The target endpoint was secret-cors-2.php running on 127.0.0.1:8085

Step 1: Reconnaissance — Checking Response Headers

The first step was to inspect the response headers from the target endpoint to understand what CORS policy was in place. There was no visible Access response header, but on the website it said only request from intranet.itsecgames.com will reveal the secret.

Step 2: Add Origin to request header and observe response

The response showed it allowed only requests from this header, but no credentials need to be set. So I tried to make a request to the endpoint that just specifies the Origin but does not check credentials if it is actually from an actual authenticated user.

Step 3: Use Curl to send request

I used curl to send a request to the endpoint without the cookies and it validating if the Origin set is actually coming from that specific endpoint, and it revealed the secret.

CSRF Exploitation on VulnBank

VulnBank is a deliberately vulnerable banking application running at 172.21.0.3:5000. Two endpoints were tested — a card freeze toggle and a money transfer.

Step 1 — Toggle Card Freeze Endpoint Exploitable

Navigating to the toggle freeze endpoint and captured via Burp Suite. The request had no body and no Content-Type header, making it a simple CORS request with no preflight triggered.

Step 2 — Host payload on my local server

Step 3 — Go to localhost and load the payload

Because it was a simple request, the browser sent it cross-origin without a preflight check, and the cookie went with it automatically.

This is very dangerous and in a real banking environment can affect real customers.

Endpoint 2 — Money Transfer: Not Exploitable (Partial Misconfiguration)

The transfer endpoint required a JSON body, which changed the request classification from simple to non-simple — triggering a CORS preflight.

All these were present in preflight Access-Control-Allow-Origin: http://localhost:8090 Access-Control-Allow-Headers: content-type Access-Control-Allow-Methods: POST, GET, OPTIONS

but Access-Control-Allow-Credentials: true was missing.

Step 2- Crafted an exploit payload

The preflight OPTIONS response was missing Access-Control-Allow-Credentials: true. Without this, the browser refuses to send a credentialed cross-origin request, even though every other condition for exploitation was met.

Was met with an error which showed it was expecting an ACAC header and it was not seen, hence the error shown below.

Vulnerabilities and Risk Levels

1. bWAPP CORS Misconfiguration — High
2. CSRF on Toggle Freeze — High
3. Partial CORS Misconfiguration on Transfer — Medium

Key Lessons from This Labs

1. The CORS headers tell you exactly what kind of cross origin attacks are possible.
2. ACAO: * and credentials: include are mutually exclusive in browsers
3. Check ACAO header -> if reflects origin + ACAC:true ->can read responses cross-origin
4. Check for CSRF token ->check SameSite ->check if request header -> write PoC -> verify action executed on server

Thank you for reading :). Kindly share if you find insightful.