Comprehensive Guide to Understanding CORS
This document details why Cross-Origin Resource Sharing (CORS) acts as a browser-level sandbox and demonstrates how data flows between clients and servers during CORS restrictions.
1. Why Postman Works vs. Why Browsers Block Requests
The fundamental difference lies in where the security check happens. CORS is not a server-side firewall; it is a browser-enforced security contract.
| Feature | Web Browser (Chrome, Safari, Firefox) | Postman Client / Backend Server |
|---|---|---|
| Enforces CORS? | Yes | No |
| Sandbox Environment? | Yes (Isolates origins to protect user sessions) | No (Direct terminal/application environment) |
Sends Origin Header? |
Automatically attached by the browser engine | None (Unless manually configured by user) |
| Action on Mismatch | Blocks code from reading the response | Delivers full payload directly to interface |
2. Request-Response Cycle for Simple Requests (e.g., GET)
For simple requests, the server always processes your data. The browser blocks the incoming response after it leaves the server if headers are missing.
+-------------------+ 1. GET Request +-------------------+
| WEB BROWSER | ---------------------------------> | API SERVER |
| (domain-a.com) | | (://domain-b.com) |
+-------------------+ +-------------------+
^ |
| | 2. Processes logic
| | Saves to database
| | Generates response
| 3. Response Payload v
+------------------------------------------------- [ Sends Data ]
|
[ Browser Check ]
Does Response Header contain:
'Access-Control-Allow-Origin: domain-a.com'?
|
+---> NO ==> [ CORS Error ] Response blocked from JavaScript.
|
+---> YES ==> Data successfully passed to frontend app.
Critical Side Effect
Because the server executes the action before the browser evaluates the security header, data modifications (like database updates) will still occur on the backend. Only the client application is prevented from reading the confirmation or result.
3. Request-Response Cycle for Complex Requests (The Preflight Check)
For non-simple requests (like sending JSON payloads via POST, PUT, or DELETE), the browser performs a safety preflight handshake using the HTTP OPTIONS method before executing your actual logic.
Scenario A: Failed Preflight (Server Denies Cross-Origin Access)
+-------------------+ 1. OPTIONS Request +-------------------+
| WEB BROWSER | ---------------------------------> | API SERVER |
| (domain-a.com) | "Are you open to domain-a?" | (://domain-b.com) |
+-------------------+ +-------------------+
^ |
| | 2. Evaluates Origin
| 3. Refusal Response v
+------------------------------------------------- [ Sends 400/403 ]
|
[ Browser Check ]
Preflight Refused!
|
+---> [ CRITICAL STOP ]
The browser cancels the workflow.
The actual POST/PUT request is NEVER sent.
Server data remains completely untouched.
Scenario B: Successful Preflight & Actual Request Lifecycle
+-------------------+ 1. OPTIONS Request +-------------------+
| WEB BROWSER | ---------------------------------> | API SERVER |
| (domain-a.com) | "Are you open to domain-a?" | (://domain-b.com) |
+-------------------+ +-------------------+
^ |
| 2. Access Allowed Response v
+------------------------------------------------- [ Sends 200 OK ]
| (Access-Control-Allow-Origin)
[ Browser Check ]
Preflight Passed!
|
| 3. Actual Request +-------------------+
+----------------- (POST / PUT / DELETE) --------------> | API SERVER |
| | Processes logic |
| | Modifies data |
| +-------------------+
| |
| 4. Actual Response |
+------------------------------------------------------------------+
4. Summary of Key Takeaways
Postman succeeds because it acts as a direct backend client; it does not implement or respect browser origin restrictions.
Servers always process simple cross-origin requests, even if the browser throws a CORS error right afterward.
Preflight checks protect your infrastructure by catching illegal cross-origin configurations before state-changing mutations (
POST/PUT/DELETE) hit your core business logic.
