A simple web application designed to help you understand Cross-Origin Resource Sharing (CORS) security mechanisms and common misconfigurations.
CORS Playground is an intentionally vulnerable web application that demonstrates various CORS configurations and their security implications. By default, it comes with CORS configured in unsafe ways that can be easily exploited from different origins. This makes it an excellent learning tool for understanding CORS behavior, session cookie handling, and web application security.
- Learn how CORS policies work in real-world scenarios
- Understand the interaction between CORS and cookie SameSite attributes
- Practice identifying and exploiting CORS misconfigurations
- Test different origin scenarios (same origin, subdomain, different domain, etc.)
- Experiment with various cookie security settings
- Multiple CORS Modes: Switch between 6 different CORS configuration modes
- Cookie Configuration: Test different SameSite cookie attributes (None, Lax, Strict)
- Multiple Test Domains: Test CORS behavior from various origin types
- HTTPS Support: Runs over HTTPS with self-signed certificates
- Interactive UI: Web interface to test attacks from different origins
- Debug Logging: Console logs to observe CORS request/response behavior
- Node.js (v14 or higher)
- npm
- Clone the repository:
git clone <repository-url>
cd cors_playground- Install dependencies:
npm install- Configure your hosts file (
/etc/hostson macOS/Linux,C:\Windows\System32\drivers\etc\hostson Windows):
# Domain for the CORS playground application itself
127.0.0.1 playground.cors.test
# Same level domain as playground.cors.test
127.0.0.1 project.cors.test
# Subdomain of playground.cors.test
127.0.0.1 pts.playground.cors.test
# Parent domain .com.au
127.0.0.1 pts.playground.cors.test.com.au
# Parent domain of playground.cors.test
127.0.0.1 cors.test
# A totally different domain
127.0.0.1 another.domain.com
- Start the server:
node app.js- Access the application:
https://playground.cors.test:5555
Note: You may need to accept the self-signed SSL certificate warning in your browser.
- Username:
mduarte - Password:
Pa55w0rd1
POST /login.html- Authentication endpointGET /main_page.html- Main application page (requires authentication)GET /- Redirects to login or main page based on sessionGET /logout- Clears session and logs out userGET /api/v2/accounts- Protected API endpoint (requires authentication)GET /api/v1/accounts- Legacy API endpoint (intentionally unsecured for testing)GET /cors_attack.html- Attack demonstration page
The application supports 6 different CORS modes that can be configured via the login form:
Only origins in the allowedOrigins array are permitted:
https://cors.test:5555https://pts.playground.cors.test:5555
Allows any subdomain matching .playground.cors.test (vulnerable to regex bypass)
Only allows the default app origin: https://playground.cors.test:5555
Sets Access-Control-Allow-Origin: * (incompatible with credentials)
Reflects whatever origin the request came from (highly vulnerable)
Sets Access-Control-Allow-Origin: null (exploitable from sandboxed iframes)
The application allows testing three SameSite cookie settings:
- None: Cookie sent with all cross-site requests (requires
Secureflag) - Lax: Cookie sent with top-level navigation but not with cross-site subrequests
- Strict: Cookie only sent with same-site requests
- Log in to the application at
https://playground.cors.test:5555 - On the main page, you'll see buttons for testing CORS attacks from different origins
- Click any button to open
/cors_attack.htmlfrom a different domain - Use browser DevTools or a proxy (like Burp Suite) to observe:
- Origin headers in requests
- CORS headers in responses
- Cookie behavior with different SameSite settings
- Whether requests succeed or fail based on CORS policy
Scenario 1: Reflect Mode with Credentials
- CORS Mode: 5 (Reflect)
- SameSite: None
- Attack from:
another.domain.com - Result: Attack succeeds, credentials sent, data leaked
Scenario 2: Subdomain Bypass
- CORS Mode: 2 (Subdomains)
- Test from domains containing
.playground.cors.test - Try bypass techniques in the origin header
Scenario 3: Wildcard with Credentials
- CORS Mode: 4 (Any Host)
- Result: Browser blocks credential sharing with wildcard origin
The application contains mock sensitive account data at /api/v2/accounts:
{
"1": {
"username": "mduarte",
"Full Name": "Marta Carolina Duarte Diaz",
"Roles": "Administrator",
"API-key": "916f4c31aaa35d6b867dae9a7f54270d"
},
"2": {
"username": "jsmith",
"Full Name": "Joseph Smith",
"Roles": "User",
"API-key": "71694f4302eacf0b9faeef686bc1da31"
},
"3": {
"username": "ppicapiedra",
"Full Name": "Pedro Picapiedra",
"Roles": "Operator",
"API-key": "e75c2b1971d188a45fe4213d9e48a52a"
}
}- Framework: Express.js 5.x (ES Modules)
- Port: 5555 (HTTPS)
- Protocol: HTTPS only
- Session Management: HttpOnly cookies
- Certificate: Self-signed (located in
/cert/directory)
- CORS allows servers to specify which origins can access resources
- By default, browsers block cross-origin requests for security
- CORS headers explicitly allow certain cross-origin requests
- Reflected Origin: Reflecting any origin without validation
- Regex Bypass: Poor subdomain validation using vulnerable regex
- Null Origin: Trusting the
nullorigin value - Legacy Endpoints: Unsecured old API versions left accessible
- Use explicit allowlist of trusted origins
- Never reflect origin headers without strict validation
- Avoid wildcard (
*) when credentials are needed - Validate origin against strict patterns, not regex
- Remove or secure legacy API endpoints
- Use appropriate SameSite cookie attributes
- Combine CORS policies with proper authentication
The application includes console logging to help you understand CORS behavior:
console.log('CORS Mode:', CURRENT_CORS_MODE, ' - Origin header received:', origin_req_header);Check your terminal/console output when making requests to see how the server processes CORS headers.
- Security Training: Learn about CORS vulnerabilities in a safe environment
- Penetration Testing Practice: Practice identifying and exploiting CORS issues
- Developer Education: Understand how to properly implement CORS policies
- Bug Bounty Preparation: Train for real-world CORS vulnerability discovery
- This application is intentionally vulnerable for educational purposes
- DO NOT deploy this application to production or public-facing environments
- Use only in isolated development/testing environments
- Self-signed certificates will trigger browser warnings (this is expected)
If you encounter SSL certificate errors:
- Accept the certificate warning in your browser
- Or generate new certificates using
openssl
- Ensure you edited the hosts file with administrator/root privileges
- Clear your DNS cache after modifying hosts file:
- macOS:
sudo dscacheutil -flushcache - Windows:
ipconfig /flushdns - Linux:
sudo systemd-resolve --flush-caches
- macOS:
If port 5555 is already in use:
- Stop any other instances of the app
- Or modify the
server_portvariable inapp.js
This is an educational tool. If you have suggestions for additional CORS scenarios or improvements, feel free to contribute!
This project is provided for educational purposes only.
This application contains intentional security vulnerabilities for educational purposes. The authors are not responsible for any misuse of this application. Use only in authorized testing environments where you have explicit permission.