CORS (Cross-Origin Resource Sharing) is a set of HTTP headers that lets a server tell a browser which websites may read its responses. It creates a limited exception to the browser’s same-origin restrictions; it is not a universal barrier that prevents every kind of network request.
What counts as a different origin?
An origin is the combination of a page’s scheme, host, and port. For example, https://app.example and http://app.example are different origins because their schemes differ. Different ports also mean different origins. A path difference alone does not: https://app.example/profile and https://app.example/settings share an origin.
As an Amazon Associate I earn from qualifying purchases.
The browser’s same-origin policy limits how scripts from one origin can interact with resources from another. Without that restriction, a malicious page could try to use a visitor’s browser session to read private information from a site where the visitor is signed in, then send that information elsewhere.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →How does CORS decide whether JavaScript can read a response?
Suppose JavaScript on https://site-a.example calls fetch() for a resource on https://site-b.example. The browser includes an Origin header in the request. The server can respond with Access-Control-Allow-Origin naming the origin it permits, or use * for a public resource that does not require credentials. The browser checks the response headers and exposes the response to the calling script only if the CORS policy allows it. See MDN’s CORS guide and Access-Control-Allow-Origin reference.
#1 Best Overall
This is primarily a control over whether browser-based script can read a cross-origin response. It does not mean browsers forbid every cross-origin request: navigation, embedding, and some forms of sending requests follow other rules. A CORS failure also does not prove the server never received a request.
When does a browser send a preflight request?
For some cross-origin requests, the browser first checks permission with an OPTIONS request. This preflight describes the method and any non-safelisted headers the script intends to use. The server responds with its CORS policy; if the policy allows the planned request, the browser proceeds with the actual request. The details are described in MDN’s preflighted requests documentation.
A preflight is a browser protocol check, not proof that a request is harmless or that a user is authenticated. It asks whether the server permits the browser to make the planned cross-origin request under CORS.
How do credentials change the required headers?
When a request includes credentials such as cookies, the server cannot authorize it with Access-Control-Allow-Origin: *. It must return the specific trusted origin and explicitly allow credentials when they are needed. MDN explains the relevant rules in its credentialed requests guidance.
- For public, non-credentialed resources,
Access-Control-Allow-Origin: *can be appropriate. - For credentialed access, return an explicit origin from a trusted allowlist rather than blindly reflecting whatever value arrives in
Origin. - Grant access only to the origins and resources the application needs.
CORS is not a substitute for authentication, authorization, or defenses against cross-site request forgery. Those controls answer different security questions.
What should a server return when access varies by origin?
If a server chooses its CORS response based on the incoming Origin, it should also send Vary: Origin. That tells caches that the response can differ depending on the request’s origin, reducing the risk of serving a response with the wrong CORS headers. See MDN’s CORS and caching guidance.
Avoid using Access-Control-Allow-Origin: null as a shortcut. Some opaque or sandboxed origins serialize as null, so allowing it can authorize a broader set of contexts than intended; MDN discusses this risk in its header reference.
Why am I getting a CORS error, and how can I fix it?
Browsers deliberately give JavaScript limited details about CORS failures, so the console is usually more informative than the error reported by the script. Check the page’s origin, the requested URL, and the request and response in the browser’s Network panel.
Best Value
- Identify the page origin: scheme, host, and port.
- In the browser console and Network panel, locate the failed request and inspect whether it was preceded by an
OPTIONSpreflight. - Check that the server’s response allows the page origin and, where applicable, the requested method, headers, and credentials.
- If the server is not yours, ask its owner to authorize browser access or use a server-side intermediary only when your application is legitimately permitted to access the resource.
Frontend JavaScript cannot add permission headers to another server’s response. The server that serves the resource must provide the appropriate CORS response headers.
Does mode: 'no-cors' bypass CORS?
No. In fetch(), mode: 'no-cors' restricts which requests the script can make and gives it an opaque response, whose body and headers are not readable by JavaScript. It does not turn a protected cross-origin response into readable data. MDN covers this behavior in its CORS and no-cors mode documentation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
