Cross-Origin Resource Sharing definition
CORS (Cross-Origin Resource Sharing) is a browser security mechanism that lets a server declare which other origins, meaning combinations of scheme, domain and port, may read its responses from JavaScript. Browsers block such cross-origin reads by default under the same-origin policy; CORS headers such as Access-Control-Allow-Origin selectively relax that rule for trusted front ends.
The same-origin policy and why CORS exists
Browsers enforce the same-origin policy: JavaScript on https://app.example.com cannot read responses from https://api.other.com unless that server allows it. The rule stops a malicious page from silently reading your bank balance or email using the cookies your browser already holds. It applies only to browsers; server-to-server calls, mobile apps and tools like curl are not restricted by it.
Modern apps often split front end and API across origins, for example a React app on app.example.com calling api.example.com, or a single-page application calling a third-party service. CORS is the standard way for the API to say which of those front ends it trusts and what they are allowed to send.
How CORS works: simple and preflight requests
For simple requests, such as a GET without custom headers, the browser sends the request with an Origin header. If the response includes Access-Control-Allow-Origin matching that origin, or a wildcard, the browser lets JavaScript read it; otherwise it blocks the response and logs a CORS error in the console, even though the server may have processed the request.
Requests that could change data or use custom headers, such as a PUT with JSON or a request carrying an Authorization header, trigger a preflight. The browser first sends an OPTIONS request asking which methods and headers are allowed, and sends the real request only if Access-Control-Allow-Methods and Access-Control-Allow-Headers permit it. Access-Control-Max-Age lets browsers cache that answer and skip repeated preflights.
How to fix CORS errors safely
Most CORS errors are configuration problems that look like code bugs. Our HTTP status codes reference helps when a preflight fails with an unexpected status. A safe fix usually follows these rules rather than switching protections off:
- Configure CORS on the server or API gateway; client code cannot grant itself permission
- Return allowed origins from an explicit allowlist instead of reflecting whatever Origin arrives
- Never pair a wildcard origin with credentials; reflecting arbitrary origins with credentials is a serious vulnerability
- Handle OPTIONS requests properly, since some frameworks and proxies drop them
- Make sure error responses such as 401 or 500 also include CORS headers, or the real error hides behind a CORS message
- In development, use a dev server proxy rather than disabling browser security
CORS is not an authentication system
CORS controls which web pages can read responses in a browser; it does not protect an API from direct calls. Attackers can call your API from scripts or servers that ignore CORS entirely, so every endpoint still needs authentication, authorization and rate limiting. CORS also does not stop cross-site request forgery for form posts; SameSite cookies and CSRF tokens handle that. Treat CORS as one layer alongside the OWASP Top 10 protections.
When a CORS error appears, open the browser Network tab and inspect the preflight request and its response headers before changing any code. The console message names the missing or mismatched header, and the fix is usually a single line of server or gateway configuration.