CORS Policy Checker

CORS (Cross-Origin Resource Sharing) is a security mechanism enforced by browsers that controls which origins (domain + protocol + port combinations) can read responses from a different origin. Without CORS, a malicious site could silently make authenticated requests to your bank or API using your cookies. CORS does NOT affect server-to-server requests — only browser-initiated ones. curl and Postman ignore CORS entirely.

A preflight is an automatic OPTIONS request the browser sends before a 'non-simple' cross-origin request. Non-simple requests include any method other than GET/HEAD/POST, custom headers like Authorization, or Content-Type values other than form types. The browser checks the OPTIONS response for Access-Control-Allow-Methods and Access-Control-Allow-Headers before sending the actual request. If the preflight fails, the real request is never sent. Use Access-Control-Max-Age to cache preflight results and avoid repeated OPTIONS round-trips.

The wildcard (*) allows any origin to read the response. It is appropriate for fully public APIs that return no user-specific data — for example, a public weather API or open data endpoint. You must NOT use * when: (1) the endpoint returns sensitive or user-specific data, (2) the client sends credentials (cookies or Authorization headers) — browsers will reject wildcard + credentials as invalid, or (3) you want to restrict access to known partners. In those cases, explicitly list trusted origins and reflect the matching one in the response.

No — this combination is explicitly invalid per the CORS specification and all modern browsers will block the response with an error. When credentials mode is enabled (fetch with credentials: 'include', or XMLHttpRequest with withCredentials: true), the server must respond with an explicit origin (e.g. Access-Control-Allow-Origin: https://yourapp.com) rather than *. The server must also set Access-Control-Allow-Credentials: true. This prevents credential-bearing requests from being silently accepted by every site on the internet.

CORS and CSRF (Cross-Site Request Forgery) are complementary but different protections. CORS controls whether a browser allows a script to READ a cross-origin response. CSRF protects against a malicious site WRITING (sending requests) on behalf of a logged-in user without their consent. CORS does not prevent CSRF — simple GET/POST requests that don't read responses can still be CSRF attacks. You need CSRF tokens or SameSite cookie attributes to defend against CSRF. Together, both protections provide layered defense for cross-origin interactions.

CORS is a browser-only enforcement mechanism. curl, Postman, server-side Node.js, Python scripts, and all non-browser HTTP clients never check or enforce CORS headers — they always send and receive responses regardless. This is why testing with curl may succeed while your frontend React or Vue app gets blocked. The fix is always on the server side: add the correct Access-Control headers to your API responses. The browser reads those headers and decides whether to expose the response to your JavaScript code.