EXERCISE 2 — Why CORS does NOT protect against CSRF
====================================================

WHAT CORS ACTUALLY GOVERNS:
  - CORS (Cross-Origin Resource Sharing) controls whether JavaScript running
    on origin A is allowed to READ a response from origin B.
  - It is a RELAXATION mechanism layered on the Same-Origin Policy: by
    default JS can't read cross-origin responses; CORS headers
    (Access-Control-Allow-Origin, etc.) let a server opt in to permitting
    certain origins to read its responses.
  - KEY POINT: CORS is about READING RESPONSES. It is NOT about whether a
    request may be SENT, nor whether the server processes it.

WHY A FORGED POST STILL EXECUTES:
  1. evil.com submits a form POST (or a credentials:'include' fetch with a
     simple content type) to yourbank.com/transfer.
  2. The browser SENDS the request -- cross-site sending of credentialed
     requests is allowed (the CSRF gap). The victim's cookie is attached.
  3. yourbank.com's server RECEIVES and PROCESSES the request like any
     other: it sees a valid session cookie, authorizes, and performs the
     transfer. The server acts BEFORE any CORS check is relevant.
  4. The CORS policy only kicks in for whether evil.com's JAVASCRIPT may
     READ the response. The browser may indeed block evil.com from reading
     the reply -- but by then the transfer has ALREADY HAPPENED on the
     server.
  5. The attacker doesn't care about the response. The whole goal was the
     SIDE EFFECT (the transfer), not the data. So a blocked read costs them
     nothing.

THE MYTH, STATED AND CORRECTED:
  Myth: "CORS blocks cross-origin requests, so my API is CSRF-safe."
  Reality: CORS blocks cross-origin READS of responses, not the SENDING or
  SERVER-SIDE PROCESSING of state-changing requests. A forged write executes
  regardless of CORS. CORS is not, and was never, a CSRF defence.

CAVEAT THAT CONFUSES PEOPLE:
  - For requests that AREN'T "simple" (e.g. Content-Type: application/json,
    or a custom header, or DELETE), the browser sends a CORS PREFLIGHT
    (OPTIONS) first. If the server doesn't approve it, the real request is
    never sent. That preflight CAN incidentally block some forged requests
    (Chapter 9) -- but that's the PREFLIGHT mechanism, and it only applies to
    non-simple requests. A plain form POST is "simple," gets NO preflight,
    and sails through. So you still need real CSRF defences (tokens/SameSite).