CORS: Enabling Cross-Origin Requests Safely

The Error Every Beginner Web Developer Hits

Say you are building your first real project: a marks-tracker app for your class. You build the frontend — the HTML, CSS and JavaScript that runs in the browser — and put it on GitHub Pages, so it lives at an address like https://roshni-dev.github.io. You build the backend separately — a small Node.js server that stores marks in a database — and deploy it to a free host like Render, where it lives at https://marks-api-xk2p.onrender.com. Both pieces are yours. You wrote every line. Now you add one line of JavaScript to your frontend page to fetch the marks:

fetch("https://marks-api-xk2p.onrender.com/api/marks")
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.log("Fetch failed:", error));

You open the page, check the console expecting your marks to print out, and instead see this in red:

Access to fetch at 'https://marks-api-xk2p.onrender.com/api/marks'
from origin 'https://roshni-dev.github.io' has been blocked by
CORS policy: No 'Access-Control-Allow-Origin' header is present
on the requested resource.

Nothing is broken. Your server is running fine — if you had opened the API URL directly in a new browser tab, or tested it with a tool like Postman, it would have returned the marks data without complaint. The problem exists only because your JavaScript, running inside a page loaded from one address, tried to read data from another address, and the browser itself stepped in and refused to hand the response over. This is not a bug in your code. It is a deliberate, permanent security feature built into every modern browser, called the same-origin policy, and CORS is the mechanism that lets you switch it off safely, on purpose, for the specific cases where cross-address communication is actually meant to happen. Understanding CORS means first understanding exactly what the browser is protecting, and only then how the protection is lifted.

What Exactly Counts as an "Origin"?

An origin is not just a website's name — it is a precise combination of three parts of a URL: the scheme (http or https), the host (the domain name, such as roshni-dev.github.io), and the port (the number after the host, such as :443 for HTTPS or :3000 for a local dev server; when no port is written, a default port is assumed — 80 for HTTP, 443 for HTTPS). Two URLs are same-origin only when all three parts match exactly. Change even one, and you get a different origin as far as the browser is concerned:

• https://myschool.in and http://myschool.in — different origins (scheme differs: https vs http)
• https://myschool.in and https://api.myschool.in — different origins (host differs: a subdomain counts as a different host)
• https://myschool.in and https://myschool.in:8443 — different origins (port differs)
• https://myschool.in/login and https://myschool.in/dashboard — same origin (the path after the host is irrelevant to origin comparison)

This is worth sitting with, because it surprises almost every beginner: myschool.in and api.myschool.in look like they belong to "the same website," and in casual conversation they do. But to the browser's same-origin policy, they are as unrelated as two completely different companies. This is precisely the situation in the marks-tracker example — roshni-dev.github.io and marks-api-xk2p.onrender.com are two different hosts entirely, so every request between them is cross-origin by definition, no matter how closely the two projects are related in the developer's mind.

Why the Browser Enforces This at All

To see why this restriction exists, picture a different, more dangerous scenario. Suppose you are logged into your school's fee-payment portal at https://fees.myschool.in. Logging in set a cookie in your browser that proves your identity — every request your browser sends to fees.myschool.in automatically carries that cookie along, the same way showing an ID card at every counter inside a building proves who you are without you having to re-introduce yourself each time.

Now, in another tab, you visit an unrelated site, say https://free-wallpapers-download.com, which — unknown to you — contains malicious JavaScript. That script tries:

fetch("https://fees.myschool.in/api/balance", { credentials: "include" })
  .then(response => response.json())
  .then(data => sendToAttacker(data));

Here is the critical, often misunderstood detail: the browser does send this request, cookie and all, because the cookie belongs to fees.myschool.in and the browser attaches it to any request going to that address, regardless of which tab or page triggered the request. The school's server has no way to know the request didn't come from its own legitimate page — it sees a valid, authenticated request and responds normally with your fee balance. If the browser did nothing further, the malicious script on free-wallpapers-download.com would now hold your private financial data, obtained using your own login session, without you ever entering a password on that malicious site.

This is exactly what the same-origin policy exists to stop. The browser does still let the request go out and lets the legitimate server process it — but it refuses to let JavaScript running on free-wallpapers-download.com read the response that comes back, because that response belongs to a different origin than the one the script is running on. The data reaches your browser, but your browser locks it away from the script that asked for it. The malicious page is left with an empty-handed fetch() promise that never resolves into readable data. Every one of your bank's net-banking site, your school's ERP portal, and your email inbox depends on this exact protection running silently, by default, on every page you ever visit.

How the Browser Decides: The Access-Control-Allow-Origin Header

The diagram below traces what actually happens on the wire when your browser fetches something cross-origin, and where the decision to allow or block gets made.

Trace it step by step. First, the browser attaches an Origin header to the outgoing request automatically — you never write this yourself; the browser adds it based on where the page was loaded from. Second, the request travels to the server and, for a simple request like this GET, the server processes it and sends a response regardless of who asked — the network layer does not know or care about CORS. Third, and this is the step that matters, the browser looks at the response headers before handing anything to your JavaScript. Specifically, it looks for a header called Access-Control-Allow-Origin. If that header is present and its value either matches the page's origin exactly or is the wildcard * (meaning "any origin may read this"), the browser releases the response to your then() callback as normal. If the header is missing, or contains a different origin than the one making the request, the browser discards the response before your code ever sees it, and reports the console error you saw earlier.

The fix for the marks-tracker example is therefore not something you change in the frontend at all — it is a one-line change on the backend, telling the Express server to send that header:

// On the backend, marks-api-xk2p.onrender.com
app.use((req, res, next) => {
  res.setHeader("Access-Control-Allow-Origin", "https://roshni-dev.github.io");
  next();
});

Once this header is present on every response, the browser sees a match and stops blocking. Note precisely what changed: the request itself was never the problem — it was the missing permission slip attached to the response.

Simple Requests vs. Preflighted Requests

Not every cross-origin request behaves the way the marks-tracker GET did. Browsers classify requests into two categories, and it matters which one yours falls into.

A request is called simple if it uses only the methods GET, HEAD, or POST; sets no custom headers beyond a small allowed list; and, if it is a POST, uses a Content-Type of text/plain, multipart/form-data, or application/x-www-form-urlencoded. Simple requests are sent directly, exactly as traced above — one round trip, and the Access-Control-Allow-Origin check happens on that single response.

Almost everything else is not simple — and this catches beginners off guard, because the most common way to send data to an API today is with JSON, using Content-Type: application/json, and JSON is not on the simple list. So is any request using PUT, DELETE, or PATCH, or one that adds a custom header like an authentication token. For all of these, the browser does not send your actual request first. Instead, it sends a separate, automatic "permission-check" request using the OPTIONS method, called a preflight request, before your real request goes out at all. Suppose your marks-tracker later needs to submit a new mark with:

fetch("https://marks-api-xk2p.onrender.com/api/marks", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ subject: "Computer Science", score: 92 })
});

Because the body is JSON, the browser first sends, entirely on its own, an OPTIONS request asking the server "if a script from roshni-dev.github.io sends a POST with an application/json body, will you allow it?" The server must answer with headers like:

Access-Control-Allow-Origin: https://roshni-dev.github.io
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type

Only if this preflight response grants permission does the browser then send your actual POST request with the real JSON body. If the preflight is refused or the server doesn't answer OPTIONS requests at all, the real request is never sent — this is one case where CORS genuinely does stop a request from leaving the browser, not merely stop the response from being read.

Credentials Make CORS Stricter, Not Looser

By default, a cross-origin fetch() does not send cookies at all. To include them — necessary when the cross-origin API needs to know who is logged in — you must opt in explicitly with credentials: "include". The moment you do this, the rules tighten: the server can no longer respond with the convenient wildcard Access-Control-Allow-Origin: *. It must name the exact origin, and it must additionally send Access-Control-Allow-Credentials: true. This is a deliberate design choice — a wildcard combined with credential-sharing would mean "any website on the internet may read this user's private, cookie-authenticated data," which defeats the entire point of the same-origin policy described earlier. The stricter rule for credentialed requests exists precisely to prevent that hole.

Common Misconception: "CORS Protects the Server"

A very common mistake is to think of CORS as a server-side security wall that keeps bad requests from reaching an API — similar to a firewall. This is incorrect, and the confusion causes real security bugs. CORS is enforced entirely by the browser, on behalf of the page's JavaScript. It controls one thing only: whether a script running on a web page is allowed to read the response to a cross-origin request it made. It does not stop the request from being sent (for simple requests), it does not stop the server from processing it, and — this is the important part — it does nothing at all against anyone who isn't using a browser running your JavaScript.

If someone uses curl, Postman, or a Python script with the requests library to call your API directly, CORS headers are completely irrelevant, because there is no browser enforcing anything and no page-JavaScript whose access needs restricting. Your Access-Control-Allow-Origin header could say anything, or be entirely absent, and a command-line tool will still get the full response without any blocking. This means CORS must never be treated as an access-control or authentication mechanism for an API. If your marks API should only be readable by logged-in students, that has to be enforced with real authentication — checking a login token on the server for every request — not by restricting which website origins are allowed to call it. CORS answers "which browser-loaded pages may read this response," never "who is allowed to have this data."

A Worked Trace, Start to Finish

Put the whole mechanism together by tracing one more request precisely, the way you'd trace a program's execution line by line. Suppose https://roshni-dev.github.io runs fetch("https://marks-api-xk2p.onrender.com/api/marks"), and the server has been configured with Access-Control-Allow-Origin: https://roshni-dev.github.io.

1. The browser sees the request targets a different origin (different host) than the page's own origin, so it flags this as a cross-origin request.
2. It checks whether the request is simple. Plain GET, no custom headers — yes, it's simple, so no preflight is needed.
3. The browser sends the GET request over the network, automatically attaching Origin: https://roshni-dev.github.io as a header.
4. The server receives the request, runs its normal logic to fetch marks from its database, and sends back a 200 OK response with the JSON data and the header Access-Control-Allow-Origin: https://roshni-dev.github.io.
5. The browser receives this response and compares the header's value, https://roshni-dev.github.io, against the page's own origin, https://roshni-dev.github.io. They match exactly — same scheme, same host, same (default) port.
6. Because they match, the browser resolves the fetch() promise with the response, and response.json() successfully parses the marks data for your script to use.

Now change exactly one detail: suppose the server had instead been configured with Access-Control-Allow-Origin: https://roshni-dev-old.github.io — a leftover from an earlier GitHub Pages username. Steps 1 through 4 happen identically; the server still processes the request and still returns the marks data in its response body. But at step 5, the comparison fails: https://roshni-dev-old.github.io does not equal https://roshni-dev.github.io. The browser discards the response, the fetch() promise rejects, and the console prints the CORS error — even though, underneath, the correct data was sent all the way back from the server and briefly existed inside the browser before being thrown away. This is the detail that trips up most learners: a CORS error in the console does not always mean the server failed. Often it means the server succeeded perfectly, and the browser refused to release perfectly good data because the permission header didn't name the right origin.

Active Recall

1. Are https://learn.aici.in and https://learn.aici.in:3000 the same origin or different origins? Justify using all three parts of an origin.
2. A student says: "My fetch request got blocked by CORS, so my server never received it and never ran its database query." For a plain GET request with no custom headers, is this true? Explain what actually happened instead.
3. Why can a server never legally respond with both Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true at once for a credentialed request?
4. A classmate calls your API directly using Postman and gets the full JSON response, with no CORS error at all, even though your server only sets Access-Control-Allow-Origin for one specific website. Why does Postman succeed where a browser page from a different origin would fail?
5. You change your API to accept JSON bodies via POST with a custom Authorization header. What new type of request will the browser send before your actual POST, and what must the server's response to it include?

Summary

Every browser enforces the same-origin policy by default: JavaScript running on one origin — an exact combination of scheme, host, and port — cannot read responses from a different origin, even though the request itself is usually still sent and processed by the server. This protects real data, such as your logged-in session on a banking or school portal, from being read by unrelated, potentially malicious pages you happen to have open at the same time. CORS is the controlled, server-driven exception to this rule: by sending headers like Access-Control-Allow-Origin, a server explicitly names which origins are permitted to read its responses, and the browser checks this header before releasing data to the requesting script. Simple requests are checked in a single round trip; requests with JSON bodies, non-simple methods, or custom headers trigger an automatic OPTIONS preflight check first, and only proceed if that preflight is granted. Credentialed requests tighten the rule further, forbidding the wildcard origin. And crucially, CORS is enforced only inside browsers acting on behalf of page JavaScript — it is not a server firewall, does nothing against direct API calls from tools like curl or Postman, and must never be relied on as a substitute for real authentication.

Think About It

Think about this: How would you explain cors: enabling cross-origin requests safely to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where cors: enabling cross-origin requests safely is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting cors: enabling cross-origin requests safely to at least 3 other topics you have studied.