What Is CSRF and How to Prevent It

1What Is CSRF?

Cross-site request forgery (CSRF) is an attack that tricks a logged-in user's browser into sending a request the user did not intend — to a site where they are authenticated. Because the request rides on the victim's existing session, the target site treats it as a legitimate action.

The attacker never sees the response or steals the session; they simply cause an action to happen. If a bank lets you transfer money with a form submission, a malicious page can forge that submission while you are logged in, and your browser will attach your session cookie automatically.

2How the Attack Works

CSRF exploits a simple browser behavior: cookies for a site are sent on every request to that site, regardless of which page triggered the request.

• The victim is logged in to bank.com, so their browser holds a valid session cookie.
• The attacker lures them to a malicious page with a hidden auto-submitting form.
• The form posts to bank.com/transfer with attacker-chosen parameters.
• The browser attaches the victim's bank.com cookie, and the transfer is authorized.

3CSRF vs XSS

CSRF and XSS are often confused because both involve a victim's browser, but they exploit different trust relationships.

• XSS abuses the user's trust in a site by running attacker code within that site.
• CSRF abuses the site's trust in the user's browser by forging a request from elsewhere.
• XSS can read data and hijack sessions; CSRF only triggers actions blindly.
• A site with XSS often cannot be protected from CSRF, because injected scripts can read tokens.

4The Classic Fix: Anti-CSRF Tokens

The traditional defense is a synchronizer token. The server generates a secret, unpredictable value tied to the user's session, embeds it in each form, and requires it back on every state-changing request. A forged request from another site cannot know the token, so it is rejected.

• Server places a hidden field: <input type="hidden" name="csrf_token" value="<random>">.
• The value is unpredictable and bound to the user's session.
• On submission the server compares the sent token to the expected one.
• A cross-site forgery lacks the token and fails validation.

5The Modern Fix: SameSite Cookies

SameSite is a cookie attribute that tells the browser not to send a cookie on requests originating from another site, which strikes at the root of CSRF. Modern browsers default cookies to SameSite=Lax, blocking most cross-site POST requests automatically.

SameSite=Strict withholds the cookie on all cross-site requests, while Lax allows it on top-level navigations like clicking a link. Because it is enforced by the browser, SameSite is a powerful baseline, though CSRF tokens are still recommended for sensitive actions as defense in depth.

6Common Mistakes to Avoid

CSRF sneaks back in through a few recurring oversights.

• Using GET requests for state-changing actions, which are trivially forged with an image tag.
• Disabling built-in CSRF protection to 'make the API work' instead of understanding it.
• Assuming a cookie-based session API needs no CSRF defense — it does.
• Relying on checking the Referer header alone, which can be missing or stripped.

7Best Practices

A layered approach shuts CSRF down reliably.

• Set session cookies to SameSite=Lax or Strict as a browser-enforced baseline.
• Require anti-CSRF tokens on all state-changing requests for sensitive actions.
• Use the correct HTTP method — never perform actions on GET.
• For token-based APIs using Authorization headers instead of cookies, CSRF risk is lower, but confirm cookies are not also accepted.
• Fix XSS first, since it can defeat every CSRF token.

8Key Takeaways

The essentials of preventing CSRF come down to a few durable ideas.

• CSRF forges authenticated requests by abusing the browser's automatic cookie sending.
• It causes actions as the victim but cannot read the response or steal the session.
• Anti-CSRF tokens prove a request came from your own page and are the classic fix.
• SameSite cookies stop cross-site cookie sending and are a strong modern baseline.
• Use proper HTTP methods, layer both defenses, and fix XSS first.

9Frequently Asked Questions

Q: What is the difference between CSRF and XSS? A: XSS injects and runs attacker JavaScript within a trusted site, letting it read data and hijack sessions. CSRF forges a request from another site using the victim's existing session, so it can only trigger actions blindly. They abuse different trust relationships and are fixed differently.

Q: Do SameSite cookies fully prevent CSRF? A: SameSite=Lax or Strict blocks the browser from sending session cookies on most cross-site requests, which stops the common attack. It is a strong baseline, but for sensitive actions anti-CSRF tokens are still recommended as defense in depth, especially for older browsers.

Q: Are token-based APIs vulnerable to CSRF? A: APIs that authenticate via an Authorization header rather than cookies are largely immune, because the browser does not attach that header automatically to cross-site requests. The risk returns if the API also accepts a session cookie, so make sure it does not.

Q: Why should state-changing actions never use GET? A: Because GET requests are trivially forged — a simple image or link tag on any page can trigger one with the victim's cookies attached. Using POST, PUT, PATCH, or DELETE for actions, combined with CSRF tokens, is a core part of preventing forgery.