🌍 What Is CORS? Cross-Origin Resource Sharing Explained for Developers

CORS is one of those concepts every web developer eventually runs into — usually through a confusing browser console error — without initially understanding why it exists or how to actually fix it. This guide explains it clearly.

What Is CORS?

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls whether a web page running on one origin (domain) is allowed to make requests to a different origin. By default, browsers enforce the Same-Origin Policy, blocking web pages from making requests to a different domain, protocol, or port than the one they were loaded from — CORS is the standardized mechanism that allows servers to selectively relax this restriction when appropriate.

What Counts as a Different "Origin"?

An origin is defined by the combination of protocol, domain, and port. Any difference in these three components counts as a different origin:

https://example.com          → Origin A
http://example.com           → Different origin (different protocol)
https://api.example.com      → Different origin (different subdomain)
https://example.com:8080     → Different origin (different port)

This is often surprising to beginners — even a subdomain difference or a protocol difference (HTTP vs HTTPS) is treated as a completely separate origin under this policy.

Why Does the Same-Origin Policy Exist?

The Same-Origin Policy is a foundational browser security mechanism designed to prevent malicious websites from making unauthorized requests to other sites on a user's behalf, potentially exploiting their existing authenticated sessions on those other sites. Without this restriction, a malicious page you visit could silently make requests to your bank's website using your existing logged-in session cookies, without your knowledge or consent.

How CORS Actually Works

CORS provides a controlled way for a server to explicitly tell browsers which other origins are permitted to make requests to it, through specific HTTP response headers.

Simple Requests

For straightforward requests (like a basic GET request without custom headers), the browser sends the request directly and checks the response for the appropriate CORS header before allowing the requesting page's JavaScript to access the response data.

Access-Control-Allow-Origin: https://example.com

This header tells the browser that requests from https://example.com specifically are permitted to access this response.

Preflight Requests

For more complex requests (like those using certain HTTP methods, custom headers, or specific content types), the browser first sends an automatic "preflight" request using the OPTIONS method, checking with the server whether the actual request would be permitted before sending the real request at all.

OPTIONS /api/data HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type

The server responds with headers indicating what's allowed:

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

Only if this preflight check succeeds does the browser proceed to send the actual intended request.

Common CORS Response Headers

• Access-Control-Allow-Origin: Specifies which origin(s) are permitted to access the resource. Can be a specific origin, or * to allow any origin (though this should be used cautiously, since it removes origin-based restriction entirely).
• Access-Control-Allow-Methods: Specifies which HTTP methods (GET, POST, PUT, DELETE, etc.) are permitted for cross-origin requests.
• Access-Control-Allow-Headers: Specifies which custom request headers are permitted.
• Access-Control-Allow-Credentials: Indicates whether cookies and authentication credentials can be included in cross-origin requests, requiring explicit opt-in for security reasons.

A Common CORS Error and What It Means

You've likely seen an error like this in your browser console:

Access to fetch at 'https://api.example.com/data' from origin 
'https://myapp.com' has been blocked by CORS policy: No 
'Access-Control-Allow-Origin' header is present on the requested resource.

This means your frontend application (running on myapp.com) attempted to fetch data from a different origin (api.example.com), but that server's response didn't include the necessary CORS header granting permission — so the browser blocked your JavaScript code from accessing the response, even though the request may have technically succeeded on the server's end.

How to Fix CORS Issues (Server-Side)

The fix always happens on the server you're trying to request data from, never purely on the client side — since CORS is fundamentally about the server explicitly granting permission.

Node.js/Express Example

const cors = require('cors');
app.use(cors({
  origin: 'https://myapp.com',
  methods: ['GET', 'POST'],
  credentials: true
}));

General Configuration Principles

• Be specific with allowed origins in production, rather than using a wildcard (*), particularly if credentials (cookies, authorization headers) are involved.
• Only allow the specific HTTP methods your API actually needs to expose, rather than permitting everything by default.
• Enable Access-Control-Allow-Credentials only when genuinely necessary, since combining this with a wildcard origin is explicitly disallowed by browsers for security reasons.

Common CORS Misconceptions

• "CORS is a security vulnerability." It's actually the opposite — CORS is a security mechanism, and a permissive CORS configuration can introduce risk, but CORS itself exists specifically to add a layer of protection against unauthorized cross-origin requests.
• "CORS prevents all unauthorized access to an API." No — CORS only affects requests made through a web browser's JavaScript. Server-to-server requests, or requests made through tools like Postman or curl, are entirely unaffected by CORS, since it's specifically a browser-enforced restriction.
• "You can fix CORS from the frontend code." You cannot. The server must explicitly grant permission through response headers; no amount of frontend JavaScript configuration can bypass a server that hasn't granted the appropriate CORS headers.

Final Thoughts

CORS exists to give servers explicit, granular control over which other origins are permitted to access their resources through browser-based requests, building on top of the browser's foundational Same-Origin Policy. Understanding that the fix always happens server-side, through specific response headers, clears up the most common source of confusion — and configuring it thoughtfully (specific origins rather than wildcards, particularly when credentials are involved) keeps your API both functional and appropriately protected.