What Is CSRF (Cross-Site Request Forgery)?

Cross-site request forgery (CSRF) is a web attack that tricks your browser into sending an unwanted request to a site where you’re already logged in — making it perform an action you never intended, like changing your email or transferring money. It abuses the trust a site places in your authenticated session. Here’s how CSRF works, how it differs from XSS, and how to prevent it.

Reviewed and kept current by the Coppers.io editorial team — see how we research .

What CSRF is

When you log into a site, your browser stores a session cookie and sends it automatically with every request to that site. CSRF exploits this: if an attacker can get your browser to fire off a request to a site you’re logged into, the site sees your valid cookie and treats the request as genuine — even though you didn’t mean to make it. It’s sometimes called a “one-click attack” or “session riding,” and it’s a long-standing web vulnerability tracked by OWASP .

How a CSRF attack works

A typical attack:

1. You’re logged in to a trusted site (say, your bank) in one tab.
2. You visit a malicious page — via a link, ad, or email — in another.
3. That page secretly triggers a request to the bank (a hidden form, image, or script that submits “transfer money”).
4. Your browser attaches your session cookie automatically, so the bank thinks you made the request and carries it out.

The attacker never sees your data or password — they simply make your authenticated browser act for them.

What attackers can do with CSRF

CSRF can trigger any state-changing action your account is allowed to perform, such as:

• Changing your email or password (often to hijack the account).
• Transferring funds or making purchases.
• Changing account settings or privacy controls.
• Submitting data or actions in your name.

It can’t directly read data back to the attacker — its power is in making changes.

CSRF vs XSS

They’re often confused but are opposites in a sense:

• Cross-site scripting (XSS) injects malicious scripts that run in a victim’s browser — it can both read and act.
• CSRF makes the victim’s browser send a forged request to another site — it acts but can’t read the response.

Both appear in the OWASP Top 10 family of web risks, and a site with XSS flaws can often be used to defeat CSRF defences too.

How to prevent CSRF

For developers, CSRF is well understood and very preventable:

• Anti-CSRF tokens — a unique, secret token tied to the user’s session, required on every state-changing request. The attacker’s page can’t know it. This is the core defence.
• SameSite cookies — set session cookies to SameSite=Lax or Strict so browsers don’t send them with cross-site requests.
• Check the origin/referer of requests for sensitive actions.
• Require re-authentication for critical actions (e.g. changing a password).
• Use frameworks that include CSRF protection by default, and a web application firewall as an extra layer.

Modern frameworks and SameSite cookie defaults have made CSRF far rarer than it once was — but it still appears where protections are missing.

What this means for users

You can’t patch a site’s CSRF flaw, but you reduce your exposure by logging out of sensitive accounts when done, not staying perpetually logged in to banking, and following website-security basics like avoiding suspicious links. The heavy lifting is on developers, but good habits help.

The bottom line

CSRF tricks your logged-in browser into performing actions you never intended on a trusted site, abusing the session cookie it sends automatically. It can change settings, move money, or hijack accounts — but it’s highly preventable with anti-CSRF tokens, SameSite cookies, and modern frameworks. For users, logging out of sensitive sites and avoiding shady links lowers the risk.

FAQs