CORS
/kɔːrz/ · Abbreviation · Security & Infosec · Origin: 2014
Definitions
CORS, or Cross-Origin Resource Sharing, is a browser security mechanism that controls how web pages from one domain can request resources from a different domain. By default, browsers enforce the same-origin policy, blocking JavaScript from making requests to a different origin (combination of protocol, domain, and port). CORS relaxes this restriction through HTTP headers that the server sends to indicate which origins are permitted. A preflight OPTIONS request is sent automatically for complex requests to check permissions before the actual request is made. Key headers include Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers. CORS issues are one of the most common frustrations in web development, often encountered when a frontend application tries to call a backend API hosted on a different domain or port during local development.
In plain English: A browser security rule that prevents websites from secretly making requests to other websites — the reason you sometimes get mysterious errors when your frontend tries to call your API.
CORS errors are the rite of passage for every web developer. The browser sends a preflight OPTIONS request to check if the server allows the cross-origin request. If the server doesn't respond with the right Access-Control-Allow-* headers, the browser blocks the request. The fix is always on the server side.
Example: 'I spent two hours debugging a CORS error. The fix was one line: adding our frontend domain to the Access-Control-Allow-Origin header on the API.'
Source: developer experience
Etymology
- 2004
- The first cross-origin request mechanisms emerge. Microsoft introduces XDomainRequest in IE8.
- 2006
- The W3C begins work on Cross-Origin Resource Sharing as a standard way to relax the same-origin policy.
- 2014
- CORS becomes a W3C Recommendation, standardizing how browsers handle cross-origin HTTP requests.
- 2020s
- CORS is a fundamental part of web security. Misconfiguration remains one of the most common sources of developer frustration.
Origin Story
The security policy that makes every frontend developer's life harder
**Cross-Origin Resource Sharing** was developed by the W3C and formalized in a 2014 recommendation, building on earlier work by Matt Oshry, Brad Porter, and others. It exists because of the **same-origin policy**, which browsers have enforced since Netscape 2.0 (1995).
The same-origin policy prevents `evil.com` from making requests to `bank.com` using your cookies. But legitimate cross-origin requests are common -- your frontend on `app.com` needs to call your API on `api.app.com`. CORS provides a mechanism for servers to explicitly allow specific cross-origin requests.
CORS errors are the bane of web development. The dreaded 'has been blocked by CORS policy' console message has probably generated more Stack Overflow questions than any other error. The fix is always on the server side, but the error appears in the browser -- a guaranteed source of confusion for beginners.
Coined by: W3C (Matt Oshry, Brad Porter, and others)
Context: W3C Recommendation, January 2014
Fun fact: CORS preflight requests (OPTIONS) add latency to every cross-origin API call. Some teams have wasted days debugging missing OPTIONS handlers. The Access-Control-Max-Age header caches preflight results, but its default is 5 seconds in Chrome -- leading to repeated preflight requests.