CORS is a security feature implemented by browsers that controls how web pages in one domain can request and interact with resources from another domain. It helps prevent unauthorized cross-origin access while allowing legitimate cross-origin data sharing. CORS uses HTTP headers to establish a dialog between browsers and servers, determining whether cross-origin requests should be permitted based on the origin and other factors.
Cross-Origin Resource Sharing (CORS) is the controlled exception to the same-origin policy. It lets a server opt in to sharing its responses with scripts from other origins by returning specific HTTP headers. For simple requests the browser sends an Origin header and checks the response's Access-Control-Allow-Origin before letting the calling script read the body. For methods or headers that could change state, the browser first sends a preflight OPTIONS request, and the server must approve the method, headers, and origin. When credentials like cookies are involved, the server must set Access-Control-Allow-Credentials: true and echo a specific origin rather than a wildcard. The browser enforces all of this.
CORS is frequently loosened until requests stop failing, which quietly dismantles the same-origin protections around sensitive endpoints. Reflecting the request's Origin header back into Access-Control-Allow-Origin while also allowing credentials effectively lets any site read authenticated responses on behalf of a logged-in victim, exposing account data or tokens. Trusting a wildcard, an over-broad regex that matches attacker-controlled subdomains, or the literal null origin are common mistakes. Because the failure is invisible in normal use and only appears when abused, permissive CORS on an API is a real data-exposure vector rather than a cosmetic setting.
Maintain an explicit allowlist of trusted origins and compare the incoming Origin against it exactly rather than reflecting whatever arrives. Never combine a wildcard with credentialed requests, avoid allowing the null origin, and scope permissive rules to the narrowest set of paths and methods that genuinely need them. Keep preflight caching (Access-Control-Max-Age) reasonable and re-check policies when new subdomains appear. CORS is a neutral web-platform mechanism, so the primary defense is correct server configuration and review; a client-side monitoring layer complements it by watching how third-party scripts behave, but CORS itself is owned by the endpoints you control.
Not directly. CORS is enforced by the browser and governs whether a script may read a cross-origin response; it does not stop non-browser clients like curl or a server-side proxy from reading your API. It protects users from having their authenticated responses read by other sites, not the server from being called.
The browser sends a preflight for requests that are not simple, for example those using PUT or DELETE, custom headers, or certain content types. It asks the server, via headers, whether the actual method, headers, and origin are permitted before sending the real request, preventing unexpected state-changing calls.
We answer client-side security questions every day. Bring yours.