Skip to main content
HighProtected by PowerWAF

Cross-Site Request Forgery (CSRF)

CategoryCross-SiteOWASPA01:2021 – Broken Access ControlFirst seen2001Read time7 minVerified2026-03-01
DEFINITION

Cross-Site Request Forgery (CSRF) is an attack that forces authenticated users to execute unwanted actions on a web application where they are currently logged in. By crafting a malicious request disguised as a legitimate one, an attacker can trick the victim's browser into performing state-changing operations such as transferring funds, changing email addresses, or modifying account settings — all without the user's knowledge.

How Cross-Site Request Forgery (CSRF) Works

CSRF exploits the trust that a web application has in the user's browser. When a user is authenticated, the browser automatically attaches session cookies to every request sent to that domain — including requests initiated by malicious third-party sites.

1

Victim authenticates to target site

The user logs into a web application (e.g., their bank) and receives a session cookie. The browser stores this cookie and includes it with every subsequent request to that domain.

2

Attacker crafts a forged request

The attacker creates a malicious page containing a hidden form or image tag that triggers an action on the target site — for example, a fund transfer: <img src='https://bank.com/transfer?to=attacker&amount=10000'>.

3

Victim visits the malicious page

Through phishing, social engineering, or a compromised site, the victim visits the attacker's page while still authenticated to the target application.

4

Browser executes the forged request

The victim's browser automatically attaches the valid session cookie and sends the request to the target site. The server cannot distinguish it from a legitimate user action and processes it.

Real-World Examples

2006

Netflix CSRF (account takeover)

A CSRF vulnerability allowed attackers to change Netflix account details, add DVDs to the rental queue, and change the shipping address — all by tricking users into visiting a malicious page.

2008

ING Direct CSRF (fund transfers)

A CSRF flaw in ING Direct's online banking allowed attackers to initiate fund transfers from authenticated users' accounts without their consent.

2022

WordPress CSRF vulnerabilities

Multiple WordPress plugins were found vulnerable to CSRF, allowing attackers to change site settings, create admin accounts, and inject malicious content when administrators visited crafted pages.

Impact & Risk Assessment

CSRF can lead to unauthorized fund transfers, account setting changes, email or password modifications, privilege escalation, and data manipulation. In administrative contexts, CSRF can be chained with other vulnerabilities to achieve full site compromise. The severity depends on the actions the authenticated user can perform — admin-level CSRF is particularly devastating.

How to Detect Cross-Site Request Forgery (CSRF)

Review application logs for state-changing requests originating from unexpected referrers. Monitor for requests missing CSRF tokens or with mismatched tokens. Implement SameSite cookie analysis to detect cross-origin request patterns. Use WAF rules to flag state-changing GET requests (a common CSRF vector). Test with automated scanners that check for missing anti-CSRF protections on forms.

How to Prevent Cross-Site Request Forgery (CSRF)

Implement anti-CSRF tokens (synchronizer token pattern) on all state-changing forms and AJAX requests. Set the SameSite attribute on session cookies to 'Lax' or 'Strict' to prevent cross-origin cookie inclusion. Verify the Origin and Referer headers on state-changing requests. Require re-authentication for sensitive operations (e.g., password changes, fund transfers). Never use GET requests for state-changing operations. Use the Double Submit Cookie pattern as an additional layer.

Code Examples

CSRF Attack Example (Malicious Page)
<!-- Attacker's page: auto-submitting hidden form -->
<html>
<body onload="document.forms[0].submit()">
<form action="https://bank.com/transfer" method="POST">
<input type="hidden" name="to" value="attacker-account">
<input type="hidden" name="amount" value="10000">
</form>
</body>
</html>
Secure: CSRF Token Implementation (Express.js)
import csrf from 'csurf';

const csrfProtection = csrf({ cookie: { sameSite: 'strict' } });

// Generate token for forms
app.get('/transfer', csrfProtection, (req, res) => {
res.render('transfer', { csrfToken: req.csrfToken() });
});

// Validate token on submission
app.post('/transfer', csrfProtection, (req, res) => {
// Token is automatically validated by the middleware
processTransfer(req.body);
});

PowerWAF automatically blocks Cross-Site Request Forgery (CSRF) at the edge.

Deploy in minutes. No code changes required. Free plan available.

Free plan spots are limited

Frequently Asked Questions

XSS exploits the trust a user has in a website by injecting malicious scripts that execute in the user's browser. CSRF exploits the trust a website has in the user's browser by forging requests that carry the user's valid credentials. XSS reads data; CSRF performs actions.
SameSite=Lax prevents cookies from being sent on cross-site POST requests and most cross-site navigations, blocking most CSRF attacks. SameSite=Strict provides the strongest protection but can break legitimate cross-site navigation flows. Modern browsers default to SameSite=Lax.
Yes, if the API uses cookie-based authentication. APIs that use Authorization headers with bearer tokens are not vulnerable to CSRF because the browser doesn't automatically attach custom headers to cross-origin requests.