---
id: CP-053
slug: csrf-cross-site-request-forgery
lang: en
title: "CSRF: Cross-Site Request Forgery"
description: A booby-trapped site or message can make your browser act for you on a service where you are logged in. Here is the mechanism and the defenses.
canonical_url: https://startbrain.io/cyberpedia/en/articles/csrf-cross-site-request-forgery/
markdown_url: https://startbrain.io/cyberpedia/en/articles/csrf-cross-site-request-forgery.md
publisher: Brain (https://startbrain.io)
license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
cite_as: "Brain, \"CSRF: Cross-Site Request Forgery\", Cyberpedia, 2026. https://startbrain.io/cyberpedia/en/articles/csrf-cross-site-request-forgery/ (CC BY 4.0)"
wing: 1
theme: understand_hacking
reflex: cr-018
schema: G3
updated: "2026-11-03"
translations:
  en: https://startbrain.io/cyberpedia/en/articles/csrf-cross-site-request-forgery/
  fr: https://startbrain.io/cyberpedia/fr/articles/csrf-requete-forcee-inter-sites/
  de: https://startbrain.io/cyberpedia/de/articles/csrf-websiteuebergreifende-anfragefaelschung/
  es: https://startbrain.io/cyberpedia/es/articles/csrf-falsificacion-peticiones-entre-sitios/
sources:
  - "n": 1
    title: Cross Site Request Forgery (CSRF) | OWASP Foundation
    publisher: OWASP
    url: https://community.owasp.org/attacks/csrf
    accessed: "2026-11-03"
  - "n": 2
    title: Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core
    publisher: Microsoft
    url: https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0
    accessed: "2026-11-03"
  - "n": 3
    title: Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series
    publisher: OWASP
    url: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
    accessed: "2026-11-03"
  - "n": 4
    title: SameSite | OWASP Foundation
    publisher: OWASP
    url: https://community.owasp.org/SameSite
    accessed: "2026-11-03"
  - "n": 5
    title: "CWE - CWE-352: Cross-Site Request Forgery (5.0)"
    publisher: MITRE
    url: https://cwe.mitre.org/data/definitions/352.html
    accessed: "2026-11-03"
---

# CSRF: Cross-Site Request Forgery

CSRF (Cross-Site Request Forgery) is an attack that forces a user to perform unwanted actions on a web application where they are already authenticated [1]. The attacker does not need the victim's password: the attacker makes the victim's browser act.

For an employee, the typical scenario is simple. A mailbox or a banking site is open in a tab. A link received by e-mail or instant messaging leads to another page, and that page triggers, in the background, a request to the service that is still logged in [1].

## In 30 seconds

- Where it happens: on most web services without CSRF protection, when you open a booby-trapped link or page in the same browser [1].
- What the attacker wants: to trigger an action that changes something, such as a transfer or a password change [1].
- The reflex: log out of a service when you have finished using it [2].
- Where the flaw comes from: from the application, not from the user [2].

## Straight answers

### Does CSRF steal my password?

No, not as such. The attack borrows the victim's identity and rights to carry out an action in their place [1]. It targets actions that change the state of the service, such as changing the e-mail address or the password, or buying something. Forcing the victim to view data gives the attacker no benefit, because the victim receives the response, not the attacker [1].

### Why does the service obey a request I did not make?

Because it cannot tell it apart from a legitimate request. For most sites, browser requests automatically include the credentials associated with the site, such as the session cookie [1]. If the user is authenticated, the site therefore has no way to separate the forged request from the genuine one [1]. The CWE describes the weakness this way: the application does not verify, or cannot verify, that a request was intentionally provided by the user who sent it [5].

### Am I protected if the service uses HTTPS?

No. According to OWASP, HTTPS alone does not protect against CSRF, even though it remains a prerequisite for the other measures to be reliable [1].

### Does the problem come from me or from the application?

From the application. Microsoft says so plainly: CSRF vulnerabilities are fundamentally a problem of the web application, not of the end user [2]. The user's actions only limit exposure: logging out when finished and regularly clearing the browser's cookies [2].

## Inside the attacker's head

The attacker starts by spotting a request that changes something on a service, then builds an address or a script that reproduces it with their own values. OWASP gives the example of a fictional bank: the legitimate request transfers 100 dollars to a beneficiary, and the attacker replaces the beneficiary with themselves and raises the amount [1].

What remains is to get the victim to load that request while logged in. Two methods are cited: an unsolicited e-mail with HTML content, or a trap placed on pages the victim is likely to visit while using their online service [1].

The attack can also be stored on the vulnerable site itself, for example in a field that accepts HTML. It then becomes more likely: the victim is more willing to view a page of the site than an arbitrary page on the Internet, and is necessarily already logged in there [1].

## What you see on screen

Often, nothing. The booby-trapped link can be disguised as an ordinary link, with text such as "see my photos". It can also take the form of a fake image of zero size: if it appears in an e-mail, the victim sees nothing, but the browser still sends the request, with no visual sign that the operation took place [1].

```text
Neutralized illustration, not a real address.
Disguised link: displayed text "See my photos", hidden address
hxxp://banque[.]exemple[.]invalid/virement?dest=[attacker's account]&montant=[high]
Variant: invisible image in an e-mail, loaded without a click.
```

If the service expects a POST request, the attacker can host on their site a form with hidden fields. The victim believes it does something else and clicks, or else a script sends it automatically when the page loads [1]. In both cases, the page displayed is ordinary and the action takes place elsewhere.

## Under the hood

The mechanism rests on normal browser behavior. Browsers store the cookies issued by an application, including the session cookies of authenticated users, and they send all of a domain's cookies with every request, whatever way that request originated in the browser [2]. Cookies are not the only thing at issue: Basic and Digest authentication are also vulnerable, because the browser automatically resends the credentials until the end of the session [2].

Several defense ideas do not work, according to OWASP [1]:

- a secret cookie, since all cookies are sent with every request;
- accepting only POST requests, since a hidden form is enough to forge one;
- multi-step transactions, as long as the attacker can predict each step;
- checking the Referer header alone, because it can be forged, and it is sometimes absent for privacy reasons.

The recommended protections, on the application side, are as follows.

- First check whether the framework already offers CSRF protection, and use it. Failing that, add anti-CSRF tokens to all requests that change state and validate them on the server side [3]. Without a token, the attacker cannot build a valid request [3].
- For stateless software, use a double-submit cookie, preferably signed [3].
- Set the SameSite attribute on session cookies [3]. With the strict value, the browser does not send the cookie on cross-site requests, even when following an ordinary link. With lax, it sends it for a link followed from another site but withholds it on methods exposed to CSRF such as POST [4]. With none, no protection is offered [4].
- Check the origin with standard headers, notably Sec-Fetch-Site, supported by all major browsers since March 2023 [3].
- Do not use GET requests for operations that change state [3].

These measures have limits. SameSite=Lax lets top-level navigation GET requests through: an endpoint that changes state via GET remains vulnerable [2]. Older browsers may not enforce SameSite [2]. And an XSS flaw can bypass all anti-CSRF protections; the Samy worm, for example, used an XMLHttpRequest to obtain the CSRF token and forge requests [1][3]. The default behavior of SameSite varies: in December 2024, lax was the default in Chrome, Edge and Opera, but in no version of Firefox or Safari, hence the advice to set it explicitly [4].

## Case files

### 2008: the uTorrent exploit

OWASP cites, as a real example of a CSRF attack against an application working through GET requests, an exploit targeting uTorrent dating from 2008. It was used on a large scale to download malware [1]. The source says no more: neither the number of victims nor the means of distribution.

### Flaws cataloged by the CWE (identifiers from 2004 to 2009)

CWE-352 gives a selected list of observed examples, which is not exhaustive [5]. Several rely on a simple URL in an img tag: CVE-2004-1703 and CVE-2004-1995 allow user accounts to be added, CVE-2004-1842 allows gaining administrator privileges [5]. Others affect administration itself: CVE-2009-3520 allows the administrator's password to be changed, and CVE-2009-3759 allows changing passwords or shutting down a virtual machine from a web interface [5].

## Sources

1. OWASP, "Cross Site Request Forgery (CSRF) | OWASP Foundation". https://community.owasp.org/attacks/csrf (accessed 3 November 2026)
2. Microsoft, "Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core". https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 (accessed 3 November 2026)
3. OWASP, "Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series". https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html (accessed 3 November 2026)
4. OWASP, "SameSite | OWASP Foundation". https://community.owasp.org/SameSite (accessed 3 November 2026)
5. MITRE, "CWE - CWE-352: Cross-Site Request Forgery (5.0)". https://cwe.mitre.org/data/definitions/352.html (accessed 3 November 2026)

---

Original source: Cyberpedia, the public cybersecurity and AI encyclopedia published by Brain. Canonical version: https://startbrain.io/cyberpedia/en/articles/csrf-cross-site-request-forgery/
You may reuse this text freely under the CC BY 4.0 license (https://creativecommons.org/licenses/by/4.0/), provided you credit "Brain, Cyberpedia" with a link to the canonical URL above.