How CSRF Works: Cross-Site Request Forgery Explained

Written by Ruben Selby, Founder and Lead Security Consultant, Wolfcore. Last reviewed 7 November 2026.

In one sentence: CSRF is when a malicious web page tricks your browser, while you are logged in somewhere else, into sending a request that site treats as coming from you.

Part of our Hacking techniques explained library. This guide explains how CSRF works and how to prevent it.

What CSRF is

PortSwigger’s Web Security Academy defines cross-site request forgery as a vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform. It lets an attacker partly get around the same origin policy, the browser rule that stops different websites interfering with each other.

The attacker never sees your password. They borrow your logged-in session. If the action is “change the email address on this account”, and that is followed by a password reset, the account can be taken over. PortSwigger lists changing an email address, changing a password and making a funds transfer as typical targets. If the victim is an administrator, the attacker may gain control of the application’s data and functions.

How it works

PortSwigger sets out three conditions that must all be true:

A relevant action exists that the attacker wants to trigger, such as changing an email address or user permissions.
Cookie-based session handling. The site relies only on the session cookie to know who sent the request.
No unpredictable parameters. The request contains nothing the attacker cannot guess, such as the current password.

Then the attack runs like this:

You log in to a site. Your browser stores a session cookie.
You visit a page the attacker controls, usually after a link in an email or message.
That page makes your browser send a request to the site you are logged in to.
Your browser attaches your session cookie automatically, unless SameSite cookie restrictions stop it.
The site sees a valid session, processes the request and changes your account.

The same idea can arise where the browser automatically adds other credentials, such as HTTP Basic authentication or certificates.

Who it affects and how badly

Any web application where logged-in users can change things: customer portals, accountancy and legal client portals, booking and recruitment platforms, SaaS admin consoles, and the admin screens of content management systems and routers.

Sole trader to 10 staff: the likely exposure is a plugin or admin panel. Worst case is an administrator’s account changed or a site defaced.
10 to 50 and 50 to 250 staff: a custom portal where one forged request changes a bank detail or an email address. Worst case is an account takeover and a client dispute.
Regulated and 250 plus: the worst case is unauthorised changes to customer data or payments, which can mean a personal data breach under UK GDPR and the EU GDPR.

We quote no statistics here. We did not open a source that gives one.

Worked example (an illustration, not a real case)

A 15-person recruitment firm runs a candidate portal. The “change email” form relies on the session cookie alone. A recruiter, logged in, clicks a link in a message and lands on a hostile page. Without the recruiter noticing, the portal’s email address for their account is changed, then a password reset goes to the attacker. Cost: the account, a data breach report to consider, and a tense week with clients. Fix: add a per-session token to the form and set the session cookie to SameSite Strict.

What we check on a test

A general description of our method, not a client finding.

Which actions change data or settings, and whether each one carries an unpredictable token.
Whether the token is checked on the server for every method and content type, and rejected when missing.
Whether the token is tied to the user’s session, not shared or just copied into a cookie.
The SameSite setting on each cookie.
Whether any state-changing action works with a simple link (a GET request).
Same-site weaknesses, such as an insecure sibling subdomain or a stored cross-site scripting hole, which PortSwigger notes can defeat token protection.

How to detect it

Review your application’s list of state-changing requests and check each one for a token.
In logs, look for state-changing requests whose Referer or Origin header is another website, or missing.
Watch for account email, password or permission changes shortly after a user clicked an outside link.
Test in a browser: remove the token from a copy of a request and see whether the server still accepts it.

How to fix or prevent it

Add CSRF tokens to all state-changing requests. PortSwigger says tokens must be unpredictable, tied to the user’s session and strictly validated every time before the action runs.
Generate tokens with a cryptographically secure random number generator, and store them server-side in the session.
Send the token in a hidden form field using POST, not in the web address, and never only in a cookie.
Reject any request with no token, in the same way as one with a wrong token.
Set the SameSite attribute on every cookie yourself. PortSwigger recommends Strict by default, lowering to Lax only for a good reason, and never None unless you understand the risk.
Isolate user-uploaded content on a separate site from sensitive functions, because SameSite does not protect against cross-origin, same-site attacks.
Fix cross-site scripting, since one stored XSS hole can bypass CSRF tokens. See cross-site-scripting.

FAQ

Does multi-factor authentication stop CSRF? The sources opened do not say so. CSRF borrows an already logged-in session, so we make no claim that MFA prevents it. Tokens and SameSite cookies are the stated defences.

Is a CSRF token enough? PortSwigger says tokens are the most robust defence but must be implemented properly, and are bypassed by flaws such as validation that depends on the request method or on the token being present.

Is it the same as cross-site scripting? No. PortSwigger treats them as different problems: CSRF forges requests, while XSS runs script in the victim’s browser, and XSS can be used to get around CSRF tokens.

Sources

How Wolfcore helps

A Wolfcore penetration test finds this the way an attacker would, by hand, not with a scanner. Start with the free web vulnerability scan at https://wolfcore.co.uk/free-web-vulnerability-scan/ or see our web application testing at https://wolfcore.co.uk/services/web-application-penetration-testing/.