---
title: "Cross-Site Request Forgery"
canonical: https://trickest.com/glossary/csrf
description: "Cross-site request forgery makes a logged-in user's browser send an unintended state-changing request to a site that trusts the user's existing session."
last-updated: 2026-10-13
---

# Cross-Site Request Forgery

Cross-site request forgery makes a logged-in user's browser send an unintended state-changing request to a site that trusts the user's existing session.

Cross-site request forgery abuses the way browsers attach cookies to every request for a site. If a user is logged in to a bank and then visits an attacker's page, that page can trigger a hidden form post or image request to the bank, and the browser sends the session cookie along automatically. The bank sees a valid session and processes the action, whether that is a password change, a fund transfer, or an email update, without the user ever intending it.

The attack works only against state-changing requests that rely on the session alone for authorization. Defenses break that assumption: anti-CSRF tokens tied to the session, the SameSite cookie attribute that stops cross-origin cookie sending, and checks on the Origin or Referer header. CSRF appears in the [OWASP Top Ten](/glossary/owasp-top-ten) history and remains a staple of [web application security](/glossary/web-application-security) testing.

CSRF pairs badly with other flaws. A reflected [XSS](/glossary/xss) bug can defeat token defenses, and weak server-side checks blur into [broken access control](/glossary/broken-access-control) when actions run without verifying who asked.

In a Trickest workflow you crawl an application's state-changing endpoints and flag forms and APIs that lack token or SameSite protection, surfacing candidates for manual confirmation across a large target set.

## CSRF vs XSS: what's the difference?

| | CSRF | [XSS](/glossary/xss) |
|---|---|---|
| What the attacker controls | A page the victim visits, which triggers a request | Content the victim's browser executes, injected into a page the victim trusts |
| What the browser does | Sends the victim's session cookie with a forged request | Runs the attacker's script with the site's own origin |
| What the server trusts | The session cookie alone, without proof of intent | Whatever the page outputs, including injected markup |
| Primary defense | Anti-CSRF tokens, SameSite cookies, Origin checks | Output encoding, input validation, a strict Content Security Policy |

In short: CSRF makes the user's own browser do something they never asked for; XSS runs attacker code inside the site. They also combine — stored XSS can forge requests that carry the site's own CSRF tokens.

---
_Markdown source of https://trickest.com/glossary/csrf._