EXERCISE 3 — CSRF / XSS / SSRF comparison table + the CORS point
================================================================

COMPARISON ACROSS FOUR AXES:

  Axis                         | CSRF              | XSS                  | SSRF
  -----------------------------|-------------------|----------------------|-------------------
  Who is tricked into acting?  | victim's BROWSER  | the target PAGE runs | the SERVER makes
                               | sends a request   | attacker's script    | the request
  Attacker code runs on target?| No                | YES (same-origin)    | No (server-side)
  Can read / exfiltrate data?  | No (write-only)   | YES (cookies, page,  | Yes -- whatever the
                               |                   | tokens, responses)   | server fetches
                               |                   |                      | (internal data)
  Primary defence              | anti-CSRF tokens, | output encoding,     | URL allowlist, block
                               | SameSite cookies, | CSP, input handling, | internal IP ranges,
                               | Origin/Referer    | HttpOnly cookies     | isolate metadata,
                               | checks            |                      | egress filtering

KEY READ-OFFS:
  - Only XSS runs code on the target and can read data -> most powerful, and
    it can bypass CSRF tokens (Exercise 2).
  - CSRF is write-only and browser-driven; SSRF is server-driven and can
    reach internal-only systems. They share "Request Forgery" in the name but
    the FORGER differs (browser vs server).
  - The defences are in three SEPARATE toolboxes; none overlaps. Fixing one
    class does nothing for the others.

WHY "I ENABLED CORS" FIXES NONE OF THEM AS A CSRF DEFENCE:
  - WHAT CORS DOES: it controls whether cross-origin JavaScript may READ a
    response. It is a read-permission mechanism, nothing more.
  - vs CSRF: CSRF doesn't need to read the response -- the forged request is
    SENT and PROCESSED by the server before CORS is even relevant (Chapter
    2). CORS doesn't stop the request being sent or executed. So it is NOT a
    CSRF defence. (Worse, MISconfigured permissive CORS can ENABLE attacks.)
  - vs XSS: XSS is injected code running same-origin; CORS (a cross-origin
    rule) is irrelevant to same-origin script. Doesn't help.
  - vs SSRF: SSRF is the server making outbound requests; CORS is a browser
    enforcement mechanism and plays no part server-side. Doesn't help.
  - CONCLUSION: "I enabled CORS" is the textbook example of applying the
    wrong fix because the acronyms blur together. The correct CSRF fixes are
    tokens + SameSite (+ Origin checks); CORS is unrelated.

ONE-LINE MEMORY HOOK:
  Script on the page = XSS. Browser sends the request = CSRF. Server sends
  the request = SSRF. Three actors, three toolboxes, no shared fix.