A demonstration tool to highlight the risks of misconfigured Cross-Origin Resource Sharing (CORS).
It allows security researchers to send cross-origin requests with a victim's cookies and display, side by side:
- the raw HTML response from the server
- a rendered preview of that HTML (Burp-style “Render” view)
Want to test it quickly ? let's go : https://m4txrx.github.io/CORS-POC-Exploit-Viewer/
The concept of CORS can sometimes be confusing.
I recommend reading this PortSwigger article to fully understand how it works.In simple terms: when you click Victim Click in this PoC, it simulates the action of a victim clicking a link hosted on your malicious domain. From that domain, a script forces the victim’s browser to make a request to the vulnerable target site using their own cookies/session.
What you then see in the Render panel is exactly what your attacking page would have received after the victim clicked the link.
⚠️ Disclaimer: This project is a Proof of Concept (PoC) tool intended for bug bounty hunters and penetration testers.
It is not a script designed to actually exploit CORS by tricking a real victim into clicking a malicious link.
- Provide a simple tool to illustrate CORS exploitation during pentests or awareness sessions.
- Show the difference between what the server returns (raw HTML) and what the user would see (rendered).
- Educate developers on why strict CORS and cookie settings matter.
- Input a target URL
- Send requests with
credentials: includeto carry session cookies - Dual display: Raw HTML 📝 | Rendered view 🖥️
- Inspect response headers (CORS debugging)
- Dark-themed, responsive UI
-
Clone the repository:
git clone https://github.com/M4TXRX/CORS-POC-Exploit-Viewer.git cd CORS-POC-Exploit-Viewer -
Open
index.htmlin your browser.For real tests involving
SameSite=None; Securecookies, serve the PoC over HTTPS from an external domain (e.g.,https://evil.com).
- Enter the URL of a potentially vulnerable endpoint, for example:
https://victim.com/profile.php - Click Victim Click.
- The interface will display:
- Raw HTML of the response
- Rendered view of the HTML in an iframe
- CORS response headers in a debug panel
- Demo :
Modern browsers include protections that may affect PoC behavior:
- Firefox (Enhanced Tracking Protection / Total Cookie Protection): blocks or partitions third-party cookies by default.
- Chrome: rolling out full third-party cookie blocking.
- Safari (Intelligent Tracking Prevention): heavily restricts third-party cookie usage and lifetime.
- SameSite cookies: if the session cookie is set with
SameSite=StrictorSameSite=Lax, it will not be sent in cross-site requests. For CORS PoCs to succeed, cookies generally need to be `SameSite=None; (or unset).
This means some CORS PoCs may appear to “fail” even if the server is misconfigured. For controlled testing environments you may need to:
- Temporarily disable third-party cookie protections in the browser.
- Ensure the target site’s session cookie is not restricted by
SameSite=StrictorLax. Only SameSite=None` or empty will work. Check in DevTools: Storage (Firefox) or Application (Chrome) → Cookies → column SameSite.
- Never combine
Access-Control-Allow-Origin: *withAccess-Control-Allow-Credentials: true. - Use a strict allowlist of trusted origins.
- Remove
Access-Control-Allow-Credentials: trueif not absolutely required. - Implement CSRF tokens and validate the
Origin/Refererheaders. - Configure session cookies with
HttpOnly; Secure; SameSite=Lax(orStrictwhen possible).
/CORS-POC-Exploit-Viewer
├── README.md # Project documentation
├── LICENSE # License
├── index.html # Main HTML UI
├── script.js # Core exploit logic
└── style.css # Styling (dark theme)
Distributed under the MIT License.
This project is strictly for educational and legal testing purposes only.