# 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.

```text
+-------------------+           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)

```text
+-------------------+          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

```text
+-------------------+          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

1.  **Postman succeeds** because it acts as a direct backend client; it does not implement or respect browser origin restrictions.
    
2.  **Servers always process simple cross-origin requests**, even if the browser throws a CORS error right afterward.
    
3.  **Preflight checks protect your infrastructure** by catching illegal cross-origin configurations before state-changing mutations (`POST`/`PUT`/`DELETE`) hit your core business logic.