CSRF Attacks — Cross-Site Request Forgery

Published: April 8, 2026 · Reading time: 12 min

1. What is CSRF?

CSRF (Cross-Site Request Forgery), also known as "session riding" or "one-click attack," is a type of web application attack where an attacker tricks a user's browser into executing an unwanted action on a site where the user is currently authenticated.

The key aspect of CSRF is that the attacker doesn't need to know the user's password. The browser automatically sends cookies with every request to a domain, so if a user is logged into their banking site and visits a malicious page, that page can send a request to the bank using the user's active session cookies.

2. How CSRF attacks work

Consider the following step-by-step scenario:

1. User logs into bank.com and receives a session cookie
2. Without logging out, the user visits malicious-site.com
3. The malicious site contains hidden HTML that automatically sends a request to the bank
4. The browser attaches the banking cookies to that request since they're going to bank.com
5. The bank receives the request with valid cookies and executes the action

Malicious code example

An attacker can embed a hidden form on their site:

<!-- Hidden form that auto-submits -->
<form action="https://bank.com/transfer" method="POST" id="csrf-form">
  <input type="hidden" name="recipient" value="attacker-account">
  <input type="hidden" name="amount" value="5000">
  <input type="hidden" name="currency" value="USD">
</form>
<script>document.getElementById('csrf-form').submit();</script>

Or even via a GET request using an img tag:

<!-- Invisible image that sends a GET request -->
<img src="https://bank.com/transfer?recipient=attacker&amount=5000"
     width="0" height="0" style="display:none">

3. CSRF vs XSS — key differences

4. Real-world CSRF examples

Gmail CSRF vulnerability (2007)

In 2007, a security researcher discovered a CSRF vulnerability in Gmail that allowed an attacker to add email filters to a victim's account. The attacker could create a filter that automatically forwarded all incoming emails to their address. The user would have no idea their emails were compromised.

Source: "Gmail CSRF Security Vulnerability", Petko D. Petkov, 2007

Netflix CSRF attack (2006)

Netflix had a CSRF vulnerability in 2006 that allowed an attacker to modify account details — including DVD delivery address, email, and password. The attacker could also add movies to the user's queue.

Source: Netflix Security Advisory, 2006

ING Direct CSRF (2008)

ING Direct bank had a CSRF vulnerability that allowed attackers to initiate money transfers from victim accounts. The attacker only needed to know the account number, while the victim's browser would automatically attach authentication cookies.

5. Protection methods

5.1 CSRF tokens (Synchronizer Token Pattern)

The most widely used protection. The server generates a unique, unpredictable token for each session (or each request) and embeds it in every form. When the form is submitted, the server verifies the token matches.

<!-- Server generates token and embeds in form -->
<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token"
         value="a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6">
  <input type="text" name="recipient">
  <input type="number" name="amount">
  <button type="submit">Send</button>
</form>

The attacker cannot read the token from another domain thanks to the browser's Same-Origin Policy.

5.2 SameSite cookies

A modern and effective approach. The SameSite attribute on cookies controls whether the browser sends cookies with cross-site requests:

Set-Cookie: session=abc123; SameSite=Strict; Secure; HttpOnly
Set-Cookie: session=abc123; SameSite=Lax; Secure; HttpOnly

5.3 Double Submit Cookie

The server sets the CSRF token both as a cookie and as a hidden form field. When the request arrives, the server checks that the values match. An attacker can send the cookie (browser attaches it automatically), but cannot read its value to put in the form field.

5.4 Origin and Referer header validation

The server can check the Origin or Referer header to determine where the request came from:

// Node.js middleware for Origin header validation
function csrfOriginCheck(req, res, next) {
  const origin = req.headers['origin'];
  const referer = req.headers['referer'];
  const allowedOrigins = ['https://my-site.com'];

  if (req.method !== 'GET') {
    if (origin && !allowedOrigins.includes(origin)) {
      return res.status(403).json({ error: 'CSRF detected' });
    }
    if (!origin && referer) {
      const refOrigin = new URL(referer).origin;
      if (!allowedOrigins.includes(refOrigin)) {
        return res.status(403).json({ error: 'CSRF detected' });
      }
    }
  }
  next();
}

6. Framework implementations

Django (Python)

Django has built-in CSRF protection that is enabled by default:

# settings.py — CSRF middleware is active by default
MIDDLEWARE = [
    'django.middleware.csrf.CsrfViewMiddleware',
    # ...
]

# In templates use {% csrf_token %} tag
# <form method="POST">
#   {% csrf_token %}
#   ...
# </form>

# For AJAX requests, read the token from the cookie
# and send it as the X-CSRFToken header

Express.js (Node.js)

const csrf = require('csurf');
const cookieParser = require('cookie-parser');

const app = express();
app.use(cookieParser());

// Configure CSRF protection
const csrfProtection = csrf({ cookie: true });

app.get('/form', csrfProtection, (req, res) => {
  res.render('form', { csrfToken: req.csrfToken() });
});

app.post('/process', csrfProtection, (req, res) => {
  // Request is valid, CSRF token has been verified
  res.send('Success!');
});

Spring Boot (Java)

// Spring Security includes CSRF protection by default
@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .csrf()
                .csrfTokenRepository(
                    CookieCsrfTokenRepository.withHttpOnlyFalse()
                )
            .and()
            .authorizeRequests()
                .anyRequest().authenticated();
    }
}
// In Thymeleaf template:
// <input type="hidden" th:name="${_csrf.parameterName}"
//        th:value="${_csrf.token}"/>

7. Frequently asked questions

8. References

• OWASP: Cross-Site Request Forgery (CSRF)
• OWASP CSRF Prevention Cheat Sheet
• CWE-352: Cross-Site Request Forgery (CSRF)
• RFC 7231 — HTTP/1.1 Semantics and Content
• MDN: SameSite cookies
• IBM Cost of a Data Breach Report 2023