Cross-Origin Resource Sharing (CORS) is a critical security mechanism built into modern browsers. It governs how resources (like JSON APIs, images, or custom fonts) from one domain can be requested by a script running on another domain. Without CORS, the browser's Same-Origin Policy (SOP) would block nearly all cross-domain requests.
While CORS is essential for modern web applications that rely on multiple services and microservices, its misconfiguration is a top security risk that frequently leads to data exposure, especially when authenticated sessions are involved.
The Wildcard Danger: Access-Control-Allow-Origin: *
The most common and dangerous flaw is setting the Access-Control-Allow-Origin header to a wildcard (*) when the request involves sensitive, authenticated data. This effectively disables the browser's same-origin protection, allowing any domain to read the response of a request made with a victim's cookies.
The Attack Scenario: Data Theft via Wildcard
Consider an API endpoint, /user/profile, which returns a logged-in user's private data (email, address, etc.). If your server responds with Access-Control-Allow-Origin: *, a malicious third-party site can execute the following steps:
- Victim Interaction: The victim is logged into your application and is then tricked into visiting the malicious site (e.g., via a link in a phishing email).
- Cross-Origin Request: The malicious site runs a simple JavaScript fetch call to your
/user/profileendpoint, including the user's cookies (since the server likely accepts credentials). - Data Exfiltration: Because of the wildcard header, the browser allows the malicious script to read the API's successful response. The hacker instantly steals the user's private information.
The solution is precise CORS configuration. You must restrict origins, headers, and methods to only those that your application truly needs.
Implementation: Precise Restriction
Instead of a global wildcard, always specify the exact origin(s) that are allowed to make requests.
Correct vs. Vulnerable CORS Headers
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Credentials: true // Dangerous with wildcard!Risk: Any site can read authenticated responses.
Access-Control-Allow-Origin: https://app.trusteddomain.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Credentials: trueBenefit: Only the trusted origin can read responses.
For servers that handle multiple trusted domains, the server logic should dynamically check the `Origin` header and reflect only the allowed origin back, rather than using the static wildcard.
Simulate the Wildcard Vulnerability
This simulated tool shows how a malicious site (`bad-guy.com`) can successfully fetch and display content from your API if you use the vulnerable wildcard CORS header.
Don't let convenience compromise security. Auditing your API's CORS configuration should be the first step in protecting your users' data integrity against cross-site threats. Precise header configuration is the only way forward.