EXERCISE 3 — Classify each request: easily forgeable cross-site?
================================================================

(a) GET /search?q=x  via an <img> tag
    EASILY FORGEABLE: YES.
    An <img src="https://site/search?q=x"> issues a credentialed GET from
    ANY page, no script or form needed, no preflight. The browser attaches
    the target's cookies. (Harmless here because search is read-only/safe --
    but if a GET CHANGED state, this tag would trigger it. That's why GET
    must be safe.)

(b) Form POST with application/x-www-form-urlencoded
    EASILY FORGEABLE: YES.
    This is a "simple request": method POST + a simple content type that an
    HTML <form> can natively send. No CORS preflight. The browser sends it
    cross-site with cookies attached. THIS IS THE CLASSIC CSRF VECTOR -- a
    hidden auto-submitting form (Chapter 1's attack).

(c) fetch with DELETE
    EASILY FORGEABLE: NO (effectively blocked).
    DELETE is not a "simple" method, so a cross-origin fetch triggers a CORS
    PREFLIGHT (an OPTIONS request). The browser won't send the real DELETE
    unless the server's preflight response explicitly allows that origin +
    method. An attacker's site won't be allowed, so the DELETE never fires.
    Also note: an HTML form CAN'T send DELETE at all (forms do only GET/POST).

(d) fetch sending Content-Type: application/json
    EASILY FORGEABLE: NO (effectively blocked).
    application/json is NOT one of the three simple content types, so even a
    POST with it triggers a CORS PREFLIGHT. The forged cross-origin request
    is held until the server approves the preflight; it won't, so the request
    isn't delivered. A plain <form> also cannot produce a JSON body. This is
    why JSON-only endpoints are HARDER to CSRF (Chapters 8-9).

SUMMARY:
  (a) img GET ............... forgeable (simple, no preflight)   [worst if state-changing]
  (b) urlencoded form POST .. forgeable (simple, no preflight)   [classic CSRF]
  (c) fetch DELETE .......... blocked  (non-simple -> preflight)
  (d) fetch JSON ............ blocked  (non-simple -> preflight)

RULE OF THUMB:
  "Simple requests" (GET, or POST with urlencoded/multipart/text-plain) are
  freely forgeable cross-site -> need CSRF defences. Non-simple requests
  (other methods, JSON, custom headers) get a preflight that incidentally
  blocks forgery -- but don't rely on that alone (the CORS-isn't-a-defence
  caveat). Use explicit tokens/SameSite regardless.