What Is CSRF?

Cross-Site Request Forgery (CSRF) tricks a logged-in user’s browser into sending a request they never intended to make. It abuses the fact that browsers automatically attach cookies (including session cookies) to any request sent to a site — even one triggered from a completely different, malicious website.

How It Works

Say a banking site lets you transfer money with a simple GET or POST request:

POST /transfer?to=attacker&amount=1000

If the site only checks “is this user logged in” via their session cookie — and doesn’t verify the request actually came from its own pages — an attacker can host a hidden form on a completely unrelated website that auto-submits this exact request. If a logged-in victim simply visits that malicious page, their browser sends the request with their valid session cookie attached, and the transfer goes through without them ever knowing.

Why This Is Different From XSS

CSRF doesn’t require injecting any code into the target site at all — it only needs the victim to be logged in and to visit a page the attacker controls. It exploits trust in the user’s browser/session, not a flaw in how the site renders content.

How Defenders Prevent It

• CSRF tokens — a unique, unpredictable token embedded in every form/state-changing request, which the server verifies before acting. An attacker’s forged request can’t include a token it never received.
• SameSite cookies — setting cookies to SameSite=Strict or Lax tells the browser not to send them on cross-site requests, neutralizing most CSRF automatically
• Checking the Origin/Referer header — a secondary check confirming the request actually originated from the site’s own domain
• Requiring re-authentication for highly sensitive actions (password changes, large transfers)