What Is CSRF? Cross-Site Request Forgery

CSRF, or cross-site request forgery, is a web attack that tricks a logged-in user’s browser into sending unauthorized requests to a trusted application. If the site relies on the browser’s existing session cookie and does not verify intent properly, the application may process the request as if the user chose to make it.

In simple terms, CSRF abuses the fact that a browser is already authenticated. The attacker does not usually need the victim’s password. They just need the victim’s browser to send a request on their behalf. For related background, see what is cross site scripting and what is session hijacking.

How CSRF works

CSRF succeeds by causing the victim’s browser to send a valid-looking request to a site where the victim is already authenticated.

The victim is logged in

For a CSRF attack to work, the victim usually needs an active session with the target site. That might be:

Online banking
A webmail account
A cloud admin panel
A business application
An ecommerce account
An internal company portal

If the browser automatically includes the session cookie with requests to that site, the browser is already carrying the credentials the attacker wants to misuse.

The attacker creates a malicious request

The attacker then builds a request that performs some action inside the target application. Examples include requests to:

Change a password
Update a shipping address
Modify MFA settings
Add a new admin
Trigger a funds transfer
Approve or submit a transaction

That request may be embedded in:

A malicious webpage
A compromised site
An ad
An email
A forum post
Hidden HTML elements such as forms or image tags

The attacker’s goal is to get the victim to load content that causes the browser to send the request automatically.

The browser sends the request with credentials

If the victim visits the attacker-controlled content while logged in to the target application, the browser may include the victim’s session cookie or other stored credentials in the request.

To the application, the request can look legitimate because:

The session is valid
The request came from the user’s browser
The application does not require extra proof of intent

This is what makes CSRF different from simply guessing credentials. The browser is doing exactly what browsers are designed to do: send stored authentication state to the matching site.

The application performs the action

If the target application does not have proper anti-CSRF protections, it may carry out the action immediately.

The attacker may not be able to read the response because of normal browser protections, but that often does not matter. If the requested action succeeds, the damage is already done.

Common examples of CSRF

CSRF can affect any authenticated web application that performs state-changing actions without proper safeguards.

Account setting changes

An attacker causes the browser to submit a request that changes the account email, phone number, or recovery settings.

Password or security updates

If poorly designed, a site might accept requests that disable protections or change security settings without re-verifying the user.

Administrative actions

In an admin portal, CSRF can be far more serious because the forged request may create users, change roles, or alter system settings.

Financial or transactional abuse

A vulnerable application might process requests related to purchases, transfers, or billing changes if it only checks whether the user is logged in.

Why CSRF happens

CSRF happens when an application assumes that a valid authenticated request automatically reflects user intent.

That assumption breaks down because browsers are built to send cookies automatically. Without additional checks, a request caused by an attacker can look the same as a request triggered by a real button click inside the application.

Common design problems include:

No CSRF token validation
Sensitive actions allowed through GET requests
Missing Origin or Referer validation
Weak cookie settings
No re-authentication for high-risk changes

How to prevent CSRF

Modern applications reduce CSRF risk by requiring stronger proof that the request came from the intended application flow.

Use CSRF tokens

A CSRF token is a unique, unpredictable value included in a form or request and verified by the server. If the attacker cannot guess or obtain the token, the forged request should fail.

Set SameSite cookies correctly

The SameSite cookie attribute helps limit when browsers send cookies in cross-site contexts. Proper use of SameSite=Lax or SameSite=Strict can significantly reduce many CSRF scenarios.

Validate Origin or Referer headers

For sensitive actions, the server can check whether the request originated from the expected site rather than an external page.

Avoid unsafe use of GET requests

State-changing actions should not be triggered by simple GET requests. Actions that modify data should use appropriate methods and include anti-CSRF protections.

Re-authenticate high-risk actions

For especially sensitive changes, such as password updates or payment actions, require the user to re-enter credentials or confirm with another step.

When you are likely to encounter CSRF

You are most likely to encounter CSRF in:

Web application security reviews
Penetration tests
Bug bounty reports
Secure development training
OWASP guidance
Assessments of legacy web apps and internal tools

CSRF is most relevant in applications that use cookie-backed sessions and browser-based workflows. It is less central in stateless API designs that do not automatically rely on browser cookies in the same way.

Still, it remains important because many business applications, admin consoles, support portals, and older internal systems continue to use classic browser session patterns.

CSRF vs XSS

Cross-site request forgery causes a browser to send an unauthorized request. Cross-site scripting (XSS) injects attacker-controlled script into a page. They are different vulnerabilities, though XSS can sometimes make CSRF easier by letting an attacker run code inside the trusted site context.

CSRF vs authentication attacks

CSRF does not usually bypass login directly. Instead, it abuses the fact that the user is already logged in.

CSRF vs clickjacking

Clickjacking tricks a user into clicking something unintended. CSRF tricks the browser into sending a request the user did not mean to send. Both abuse trust, but the mechanics differ.

Final takeaway

CSRF, or cross-site request forgery, is an attack that tricks a logged-in user’s browser into sending unauthorized requests to a trusted web application. The danger comes from applications that trust session cookies alone without verifying that the user intentionally initiated the action.

The best defense is layered: CSRF tokens, correct SameSite cookie settings, origin checks, safe request design, and extra verification for sensitive changes. In short, being logged in should not be the only proof that a request is legitimate.