CORS Misconfigurations: The Silent Data Leak

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that controls which websites can make requests to your API. When configured correctly, it prevents malicious sites from making authenticated requests to your backend on behalf of your users. When misconfigured, it silently allows exactly that. The tricky part is that CORS misconfigurations rarely produce visible errors in your application. Everything works fine from your perspective, but an attacker's website can also interact with your API using your users' cookies and session tokens.

The most dangerous misconfiguration is reflecting the Origin header back in the Access-Control-Allow-Origin response header. This pattern often appears when developers want to support multiple frontends or local development environments and set the allowed origin dynamically based on the incoming request. If your server reads the Origin header and echoes it back without validating it against a whitelist, any website in the world can make credentialed requests to your API. Combined with Access-Control-Allow-Credentials: true, this gives an attacker full access to any endpoint your authenticated users can reach. The fix is to maintain an explicit list of allowed origins and only return the header if the requesting origin matches the list.

The second common mistake is setting Access-Control-Allow-Origin to a wildcard (*) on endpoints that serve private data. The wildcard tells browsers that any website can read the response, which is appropriate for genuinely public APIs but dangerous for endpoints that return user-specific information. Fortunately, browsers refuse to send cookies when the wildcard is used, which limits the damage, but it can still expose data if your API uses non-cookie authentication (like API keys in query parameters). The third mistake is allowing unnecessary HTTP methods and headers in preflight responses. If your API only needs GET and POST, do not allow PUT, DELETE, and PATCH in your CORS configuration, as this expands the attack surface unnecessarily.

To audit your CORS configuration, send requests to your API from a different origin and inspect the response headers. You can do this with a simple curl command: set the Origin header to a domain you do not control and see what comes back. If Access-Control-Allow-Origin reflects the attacker's domain, you have a vulnerability. In Next.js, CORS is typically configured in middleware.ts or in individual API route handlers. Make sure every route that handles sensitive data explicitly sets the allowed origins, methods, and headers. Do not rely on framework defaults, because most frameworks default to permissive settings to avoid breaking development workflows. Locking down CORS takes about 15 minutes and eliminates an entire class of cross-origin attacks.