Cross-site scripting (XSS) and CSRF: what is the difference?
Understand how XSS and CSRF affect web applications, how they differ, and practical ways to reduce the risk.
Cross-site scripting (XSS) and cross-site request forgery (CSRF, also called XSRF) are different web security problems. Both can affect a signed-in user, but their mechanisms differ. An XSS flaw lets attacker-controlled content run as script in the context of a trusted site. CSRF causes an unwanted request to a site that accepts automatically supplied credentials, such as a session cookie. The [OWASP XSS overview](https://owasp.org/www-community/attacks/xss/) and [CSRF prevention guide](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) describe these threats.
## What is cross-site scripting?
Suppose a support portal displays a comment as executable page content instead of treating it as text. If an attacker controls that comment, a visitor’s browser may execute injected script with the portal’s origin. Depending on the application, this can expose information or allow actions as the visitor. A legitimate site that reflects a malicious input can also become a step in a wider attack, as discussed in [our browser patch-gap report](https://blog.mithril.fund/chrome-windows-patch-gap-zero-day-chain?lang=en).
Stored XSS persists attacker-controlled content for later viewers; reflected XSS sends it back in an immediate response. DOM-based XSS involves client-side code placing untrusted data into an unsafe browser operation. These descriptions can overlap: they describe different parts of the data path. See [OWASP’s XSS types](https://owasp.org/www-community/Types_of_Cross-Site_Scripting).
## What is cross-site request forgery?
Imagine a signed-in user opens an attacker-controlled page that causes their browser to send a settings-change request to another site. If the browser automatically includes a session cookie and the receiving site accepts the request without checking that it was legitimately initiated, the action can occur under the user’s session. The attacker need not read the response for the unwanted action to happen. CSRF is not simply another name for XSS.
## Reduce risk
For XSS, prefer framework escaping and safe text APIs, and apply output encoding appropriate to the exact HTML, attribute, URL or script context. Do not put untrusted data into executable script or unsafe DOM sinks. If users must supply rich HTML, use a maintained, appropriate HTML sanitizer and avoid modifying sanitized output unsafely. A carefully configured content security policy is an additional layer, not a replacement for safe rendering. See the [OWASP XSS prevention guidance](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html).
For CSRF, validate appropriate anti-CSRF tokens on the server for state-changing requests and use additional controls such as appropriate SameSite cookie settings and Origin or Referer validation when suitable. Do not rely on CORS or SameSite alone as a universal defense, and do not perform state changes through safe-method requests. Applications that do not use automatically attached credentials need a threat assessment suited to their authentication model. XSS can defeat CSRF defenses, so address both classes. See the [OWASP CSRF prevention guidance](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html).
Review data flows, test controls in the application’s real browser and authentication context, and keep dependencies current. These measures reduce risk; none establishes that a particular system is safe. Sources reviewed on 2026-10-29.