CORS Explained (Finally)

Security 👁️ 1 views Last updated Apr 26, 2026

The Red Screen of Death

Every frontend developer has experienced the exact same heart-sinking moment. You boot up your shiny new React application on localhost:3000, you make an incredibly simple fetch() request to your backend API running on localhost:8000, and the browser console instantly vomits a massive red error:

"Access to fetch at 'http://localhost:8000/api/users' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource."

In a panic, developers often install wild browser extensions to disable security, or blindly paste server configurations from StackOverflow until it works. To fix CORS properly, you must understand why the browser is trying to protect you.

The Same-Origin Policy (SOP)

Browsers enforce a draconian security rule called the Same-Origin Policy. It dictates that a website hosted at domain-a.com is strictly forbidden from making background JavaScript requests (AJAX/Fetch) to domain-b.com and reading the response.

Why is this necessary? Imagine you log into your bank at chase.com. Your browser receives an authentication cookie. Later, you accidentally visit a malicious hacker website, evil.com. Without the SOP, the hacker's JavaScript could silently send a hidden request to chase.com/api/transfer-funds. Because your browser automatically attaches your banking cookie to that request, the bank assumes it is you making the request, and your money is stolen. The Same-Origin Policy stops the malicious evil.com script from being allowed to read or interact with the chase.com servers.

Enter CORS: The Permission Slip

But what if you want to build a separate frontend (my-app.com) that legitimately needs to talk to your backend API (api.my-app.com)? Because the subdomains differ, they are considered different Origins, and the browser blocks it. Cross-Origin Resource Sharing (CORS) is the mechanism to bypass the SOP safely.

When your frontend makes a complex request (like a POST request with a JSON body), the browser pauses. Before sending the actual POST data, the browser automatically fires an invisible, empty HTTP request called the Preflight OPTIONS Request. It is basically the browser asking the backend server: "Hey, I have a script running on localhost:3000 that wants to send you a POST. Are you cool with that?"

Fixing the Server Headers

If your backend server does not explicitly respond to that preflight request with a permission slip, the browser aggressively terminates the connection and throws the red CORS error.

To fix it, your backend server must respond with specific HTTP Headers:

Access-Control-Allow-Origin: http://localhost:3000 (Tells the browser exactly which origins are allowed to communicate).
Access-Control-Allow-Methods: GET, POST, PUT, DELETE (Which HTTP verbs are permitted).
Access-Control-Allow-Headers: Content-Type, Authorization (Which custom headers the client is allowed to send).

The Ultimate Danger: You will find tutorials telling you to set Access-Control-Allow-Origin: * (allow everyone). If your API handles sensitive data or requires user authentication cookies, doing this completely negates the security of the browser, reopening the exact vulnerability the Same-Origin Policy was designed to prevent. Always explicitly whitelist your specific frontend domains.