CORS - Cross Origin Resource Sharing

Source: Dev.to

Introduction

CORS (Cross‑Origin Resource Sharing) is one of those things you don’t really learn until you run into it. Everything may work on the server side—API is up, backend is responding—yet the browser blocks the request with a “Blocked by CORS policy” error.

Why CORS Exists

CORS is a browser‑only security mechanism. Tools like Postman, curl, or other HTTP clients do not enforce CORS, so they can retrieve data even when the server does not send the appropriate headers. Browsers, however, sit between your application and the user. Without CORS enforcement, any website could silently read data from another site using the user’s logged‑in session, which would be a serious security risk.

How CORS Works

Simple Requests

For straightforward requests (e.g., GET, POST with standard headers), the browser checks the response for the required CORS headers (Access-Control-Allow-Origin, etc.). If the headers are present and match the requesting origin, the response is made available to the script.

Preflight Requests

When a request uses methods like PUT, DELETE, or includes custom headers, the browser first sends an OPTIONS request—known as a preflight request. This request asks the server:

“I want to make this request with these methods and headers. Are you okay with that?”

If the server responds with the appropriate CORS headers (Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Origin, etc.), the browser proceeds with the actual request. If not, the browser aborts the operation and logs a CORS error.

Common Misconceptions

• “Just disable CORS.”
  Disabling CORS on the client side is impossible; it’s enforced by the browser. The only way to “disable” it is to configure the server to send the correct headers, which should be done deliberately, not as a quick fix.

• CORS works in Postman but not in the browser.
  Postman does not enforce CORS, so it will show the data regardless of server headers. The browser’s block is intentional protection.

Fixing CORS Errors

1. Identify the missing header – Check the browser console for the exact error message (e.g., missing Access-Control-Allow-Origin).
2. Add the required header on the server – For development, you might allow all origins with Access-Control-Allow-Origin: *. In production, specify the exact origins that should be permitted.
3. Include other necessary headers – Depending on the request, you may also need Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Allow-Credentials.

Once the correct headers are present, the browser will allow the request, and the “CORS scary” feeling disappears.

Conclusion

Understanding CORS is a rite of passage for developers. It’s simply a set of rules that dictate which origins can communicate with your server and how they must be approved. If you’ve ever been blocked by CORS, you’re not alone—once you master it, you’ve earned a valuable badge in web development.