What is CSRF?
CSRF, cross-site request forgery, gets a victim's own browser to submit a request the victim did not mean to make, aimed at a site where they are already signed in. The attack relies on ordinary browser behavior: a site's cookies ride along on every request to that site, including requests started by a page on a different site. When the target recognizes users only by their session cookie, a forged request launched from anywhere arrives with the right cookie and appears legitimate.
How the attack runs
The attacker prepares a page they own, or one they have managed to inject content into. Two common triggers fire as soon as the victim opens it: a hidden form that submits itself, or an image tag whose source is a URL that changes something on the target site.
<img src="//bank.example/transfer?to=attacker&amount=5000">
- The victim, still signed in to the bank, opens the attacker's page.
- The browser tries to load the "image" and requests the transfer URL.
- The bank's session cookie is attached automatically.
- The bank sees a valid session and carries out the transfer.
The attacker cannot read what the site sends back, only cause the action, so CSRF goes after requests that change state: transfers, password changes and settings updates. In the logs the forged request looks routine, which is why CSRF is difficult to detect afterward.
Defenses
- Anti-CSRF tokens, also called synchronizer tokens. The site places a secret, unpredictable value in each genuine form and verifies it when the form comes back. Another origin cannot read the value, so a forged request lacks it and is refused.
- SameSite cookies. This cookie attribute tells the browser to withhold the cookie from cross-site requests, so the forged request reaches the site without a session.
- Re-authentication or a confirmation step for the most sensitive actions, as an extra layer.
- No state changes over GET. A plain GET request should never move money or change settings.
CSRF vs. SSRF vs. XSS
Similar names hide different mechanisms:
| Attack | What is fooled | Where the fix goes |
|---|---|---|
| CSRF | The victim's browser, acting on a site that trusts it | Anti-CSRF tokens and SameSite cookies |
| SSRF (server-side request forgery) | The server, which fetches a URL the attacker picked | Limiting what the server can reach |
| XSS | The victim's browser, which runs script the attacker injected | Output encoding |
If a victim's existing session cookie is what makes their unintended action succeed, the attack is CSRF, and tokens plus SameSite cookies are the answer, not output encoding.
CSRF on the CompTIA Security+ exam
CSRF is listed as an application attack under objective 2.5. Scenario wording about a logged-in user's browser being tricked into a state-changing request, or an action performed using the user's existing session without their knowledge, points at it. The tempting wrong answers are SSRF, when the server is the one fooled, and XSS, when script runs in the browser. The primary defenses are anti-CSRF tokens and SameSite cookies.