EXERCISE 2 — The SQLi / XSS parallel
=====================================

SIDE-BY-SIDE:

  Axis                    | XSS                        | SQL Injection
  ----------------------- | -------------------------- | ----------------------------
  Input becomes...        | HTML / JavaScript          | SQL
  Interpreted by          | the BROWSER                | the DATABASE
  Runs where              | client-side (victim's      | server-side (your database
                          | browser, in their session) | server)
  Breakout character      | <  (opens a tag/element)   | '  (closes a string literal)
  Primary fix             | context-aware OUTPUT        | PARAMETERIZED QUERIES
                          | ENCODING                   | (prepared statements)

  EXTRA CONTRAST:
   - XSS payload example:  <script>steal()</script>  (breaks out of text into
     markup the browser executes).
   - SQLi payload example: ' OR '1'='1  (breaks out of a string value into SQL
     logic the database executes).
   - Reach: XSS compromises the victim USER (session, page). SQLi compromises
     the DATA STORE (every record) and can bypass auth, modify/destroy data,
     even run OS commands — generally higher blast radius.

THE SINGLE ROOT CAUSE BOTH SHARE:
  - UNTRUSTED DATA IS TREATED AS CODE: input that should be inert content
    crosses a boundary where an interpreter (browser for XSS, database for
    SQLi) parses it as instructions. In both, the flaw is mixing
    attacker-controlled data into a code stream so the data gains syntactic
    power it shouldn't have.
  - Both are members of the broader INJECTION family (also command injection,
    LDAP injection, template injection, etc.) — all the same mistake in
    different grammars/targets.

WHY UNDERSTANDING ONE HELPS YOU UNDERSTAND THE OTHER:
  - The MENTAL MODEL transfers directly: "find every place untrusted input
    reaches an interpreter, and make sure it stays DATA, never code."
  - The DEFENCE SHAPE rhymes: keep data SEPARATE from the code channel.
      * XSS:  encode on output so input renders as text, not markup.
      * SQLi: parameterize so input is bound as a value, never parsed as SQL.
    Both reject the losing strategy of trying to BLOCKLIST bad input (you can't
    enumerate every payload — same lesson as the XSS course).
  - So if you internalised "data vs code" and "keep them on separate channels"
    from XSS, you already grasp the essence of SQLi; only the syntax (' vs <)
    and the target (DB vs browser) change. Conversely, SQLi's parameterization
    reinforces XSS's "encode, don't filter."

ONE-LINE TAKEAWAY:
  SQLi and XSS are the same bug — untrusted input parsed as code — at different
  targets; both are fixed by keeping data off the code channel
  (parameterize / encode), not by filtering.