Overview

CSRF and XSS are both web attacks that abuse a victim’s trusted relationship with a site, but they exploit opposite ends of that trust. CSRF forges a request using the victim’s own session cookie without ever running attacker code in the browser, while XSS smuggles injected script into a vulnerable page so it executes directly inside the victim’s browser.

Comparison Diagram

CSRFXSSVictim Browseractive session cookieAttacker Siteforged auto-submit formTarget Servere.g. bank / app backendAction Executedusing victim's cookievisits pagecookie auto-attachedno injected codeVulnerable Siterenders unsanitized inputInjected <script>runs in page's own originVictim Browserexecutes attacker JSAttacker Serverreceives stolen datainput reflected as codefull DOM accesscookie exfiltrated

Comparison Table

AspectCSRFXSS
Attack vectorForged cross-site request, e.g. an auto-submitting form or image tag on the attacker’s page that targets the victim siteMalicious script injected into a vulnerable page’s HTML or JS output, often via unsanitized user input
Trust exploitedServer’s trust that any request carrying a valid session cookie came from the legitimate userBrowser’s trust that all script served from the site’s origin is safe to execute
Where the payload runsNowhere on the victim’s browser beyond a normal HTTP request; the ‘payload’ is the request itselfAttacker’s JavaScript executes directly inside the victim’s browser, in the vulnerable site’s own origin
Prerequisite for successVictim must have an active authenticated session with the target site when the forged request firesVulnerable site must reflect, store, or render attacker-controlled input without proper sanitization or escaping
Attacker capabilityLimited to whatever action the victim’s existing session is authorized to perform, like a transfer or settings changeBroad: read cookies and localStorage, capture input, deface the page, or pivot into session hijacking
Primary defenseAnti-CSRF tokens, SameSite cookies, and origin or referer checksOutput encoding, Content Security Policy, and strict input sanitization
Typical impact scopeA single forged action, bounded by what the target endpoint allowsPotential full account takeover or persistent compromise if the injection is stored

Key Differences

  • CSRF forges a request using the victim’s existing session cookie; XSS injects attacker script that runs inside the victim’s browser.
  • CSRF requires no code injection into the target site, while XSS depends entirely on unsanitized input reaching the page.
  • XSS can read and exfiltrate data straight from the DOM, whereas CSRF is limited to blind requests with no response visibility.
  • SameSite cookies mitigate CSRF but do nothing against XSS, which is stopped primarily by CSP and output encoding.

When to Use Each

CSRF

  • Auditing state-changing endpoints: Any POST, PUT, or DELETE that relies solely on cookie auth should be reviewed for CSRF exposure.
  • Reviewing cookie-based auth systems: Sites using cookies without SameSite protection need explicit anti-CSRF tokens on sensitive actions.
  • Assessing forged submission risk: Relevant when evaluating whether an attacker’s page could trigger unwanted actions on your site via the victim’s browser.

XSS

  • Reviewing user-generated content: Comments, profiles, and search results that echo input back to the page need output-escaping review.
  • Auditing third-party script inclusion: Anywhere external or user-supplied scripts run in your origin is a direct XSS risk surface.
  • Investigating account takeover reports: Session or cookie theft complaints often trace back to an XSS injection point somewhere in the app.