What Is CSRF and How Do I Prevent It?

CSRF stands for cross-site request forgery. CSRF happens when a malicious site tricks a logged-in user’s browser into sending a request the user did not intend. It works because the browser may automatically include session cookies or other credentials, so the target application sees an authenticated request unless it has proper CSRF prevention controls in place.

How CSRF Works

CSRF is a web attack where an attacker causes a victim’s browser to perform an action on a site where the victim is already authenticated.

The attacker usually does not need to steal the victim’s password or session cookie. Instead, they rely on the fact that the browser automatically sends authentication material, often cookies, when making requests to the target site.

A typical CSRF flow looks like this:

1. A user logs in to a web application.
2. The application stores a session cookie in the browser.
3. The user visits a malicious page or clicks a crafted link.
4. That page triggers a request to the legitimate application.
5. The browser automatically includes the legitimate site’s session cookie.
6. If the target application trusts the cookie alone, it may process the request as if the user intended it.

Possible impacts include: - changing an email address - updating account settings - transferring funds - creating an admin user - altering MFA or recovery options

The browser is authenticated, but the request did not come from real user intent.

Why CSRF Happens

CSRF exists when an application relies on ambient authority, usually cookies sent automatically by the browser, and does not verify that a sensitive request came from the application’s own interface or from a deliberate user action.

From the application’s perspective, the request may look normal because it includes: - a valid session - a valid user context - a well-formed request

What is missing is proof that the request was intentional.

A Simple Example

Imagine a banking application processes this endpoint:

POST /transfer

If a logged-in user visits a malicious site that silently submits a form to that endpoint, the browser may include the banking session cookie automatically. If the bank validates only the session and not the request origin or token, the transfer may go through.

This is why CSRF is not mainly an authentication failure. It is a failure to verify intended actions.

What CSRF Is Not

CSRF is often confused with XSS, but they are different:

• CSRF abuses a victim’s authenticated browser session.
• XSS injects malicious code into a trusted page.

They can overlap in practice, and XSS can weaken or bypass some CSRF defenses, but they are separate classes of web security issues.

For a related comparison, see What Is XSS and How Is It Different From CSRF?.

How To Prevent CSRF

The best CSRF prevention strategy is layered. If your application handles sensitive actions, do not rely on a single control.

Use Anti-CSRF Tokens

This is one of the primary defenses for state-changing requests.

A CSRF token is: - unique per session or request - generated by the server - included in forms or request headers - validated by the server before the action is accepted

Because an attacker’s site should not be able to read the legitimate site’s token, it should not be able to forge a valid protected request.

Use CSRF tokens for actions such as: - account updates - payment requests - admin changes - password resets - user provisioning

Use SameSite Cookies

The SameSite cookie attribute helps limit when browsers send cookies with cross-site requests.

Common settings include: - SameSite=Strict - SameSite=Lax - SameSite=None with Secure

For many applications, Lax or Strict significantly reduces CSRF risk. The right choice depends on the application flow, especially for cross-site authentication or embedded experiences.

SameSite is an important control, but it should support, not replace, token validation for sensitive actions.

Validate Origin and Referer Headers

For state-changing requests, the server can check whether the request came from the expected origin.

This can help detect requests initiated from: - malicious third-party sites - unexpected domains - untrusted embedded contexts

Origin and Referer validation is useful defense in depth. It is strongest when combined with CSRF tokens and secure cookie settings.

Do Not Use GET for State Changes

GET requests should fetch data, not change it.

If an application performs sensitive actions through GET, it becomes easier to abuse through: - links - image tags - embedded resources - automatic browser requests

Use POST, PUT, PATCH, or DELETE for state-changing operations, and still protect those requests properly.

Require Step-Up Verification for High-Risk Actions

For especially sensitive actions, require stronger proof of user intent, such as: - password re-entry - MFA confirmation - WebAuthn verification - explicit approval prompts

This reduces the damage even if a session is active and another CSRF defense fails.

Understand Your Authentication Model

CSRF is most strongly associated with browser-based applications that use cookies for authentication. If you use token-based APIs outside normal browser cookie behavior, the risk pattern may differ.

That said, the key question stays the same: can a third-party site cause a user’s browser or client to perform an authenticated action without clear intent?

For broader context, see How Session Cookies Work in Web Apps.

Common Misconceptions

“CSRF steals my password.”

False. CSRF usually does not steal credentials. It abuses the fact that the victim is already logged in.

“HTTPS prevents CSRF.”

False. HTTPS protects data in transit. It does not prove that a sensitive request was intentional.

“Only financial sites need CSRF protection.”

Incorrect. Any application using browser-based authentication and state-changing actions can be affected, including admin portals, SaaS apps, internal tools, and HR systems.

“SameSite cookies make CSRF impossible.”

Not always. SameSite helps a lot, but application logic, browser behavior, and edge cases still matter. Sensitive actions should still have explicit request validation.

Final Takeaway

The practical rule is simple: if your application trusts a browser’s authenticated request, it must also verify that the request was intentionally made by the user. That is the core issue CSRF exploits, and that is what strong CSRF prevention is designed to stop.

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.