{“lastseen”:”2025-08-13T18:03:46″,”description”:”Cross-Site Request Forgery (CSRF) is a confused deputy attack where the attacker causes the browser to send a request to a target using the ambient authority of the user\u2019s cookies or network position.1 For example, `attacker.example` can serve the following HTML to a victim\\n \\n \\n \\u003cform action=\\”https:\/\/example.com\/send-money\\” method=\\”post\\”\\u003e\\n \\u003cinput type=\\”hidden\\” name=\\”to\\” value=\\”filippo\\” \/\\u003e\\n \\u003cinput type=\\”hidden\\” name=\\”amount\\” value=\\”1000000\\” \/\\u003e\\n \\u003c\/form\\u003e\\n \\n\\nand the browser will send a POST request to `https:\/\/example.com\/send-money` using the victim\u2019s cookies.\\n\\nEssentially all applications that use cookies for authentication need to protect against CSRF. Importantly, this is not about protecting against an attacker that can make arbitrary requests2 (as an attacker doesn’t know the user’s cookies), but about working with browsers to identify authenticated requests initiated from untrusted sources.\\n\\nUnlike Cross-Origin Resource Sharing (CORS), which is about _sharing responses_ across origins, CSRF is about accepting state-changing requests, even if the attacker will not see the response. Defending against leaks is significantly more complex and nuanced, especially in the age of Spectre.\\n\\nWhy do browsers allow these requests in the first place? Like anything in the Web platform, primarily for legacy reasons: that\u2019s how it used to work and changing it breaks things. Importantly, disabling these _third-party cookies_ breaks important Single-Sign On (SSO) flows. All CSRF solutions need to support a bypass mechanism for those rare exceptions. (There are also complex intersections with cross-site tracking and privacy concerns, which are beyond the scope of this article.)\\n\\n## Same site vs same site vs same origin\\n\\nTo protect against CSRF, it\u2019s important to first define what is a cross-site or cross-origin request, and which should be allowed.\\n\\n`https:\/\/app.example.com`, `https:\/\/marketing.example.com`, and even `http:\/\/app.example.com` (depending on the definition) are all same-site but not same-origin.\\n\\nIt\u2019s tempting to declare the goal as ensuring requests are simply from the same site, but different origins in the same site can actually sit at very different trust levels: for example it might be much easier to get XSS into an old marketing blog than in the admin panel.\\n\\nThe starkest difference in trust though is between an HTTPS and an HTTP origin, since a network attacker can serve anything it wants on the latter. This is sometimes referred to as the MitM CSRF bypass, but really it\u2019s just a special case of a _schemelessly_ same-site cross-origin CSRF attack.\\n\\nSome parts of the Web platform apply a _schemeful_ definition of same-site, where `https:\/\/app.example.com` and `http:\/\/app.example.com` are _not_ same-site:\\n\\n * Cookies in general apply the schemeless definition (HTTP = HTTPS). There is a proposal to address this, Origin-Bound-Cookies (and specifically its lack of opt-out for scheme binding, which subsumes the earlier Scheme-Bound Cookies proposal), which however hasn’t shipped yet.\\n * The SameSite cookie attribute used to apply the schemeless definition (HTTP = HTTPS). Chrome changed that with Schemeful Same-Site in 2020, but Firefox and Safari never implemented it.\\n * Sec-Fetch-Site (and the HTML and Fetch specifications in general) apply the schemeful definition (HTTP \u2260 HTTPS).\\n\\n\\n\\nUsing HTTP Strict Transport Security (HSTS), if possible, is a potential mitigation for HTTP\u2192HTTPS issues.\\n\\n## Countermeasures\\n\\nThere are a number of potential countermeasures to CSRF, some of which have been available only for a few years.\\n\\n### Double submit or synchronized tokens\\n\\nThe \u201cclassic\u201d countermeasure is a CSRF _token_ , a large random value submitted in the request (e.g. as a hidden `\\u003cinput\\u003e`) and compared against a value stored in a cookie (_double-submit_) or in a stateful server-side session (_synchronized tokens_).\\n\\nNormally, double-submit is not a same-origin countermeasure, because same-site origins can set cookies on each other by \u201ccookie tossing\u201d. This can be mitigated with the `__Host-` cookie prefix, or by binding the token to the session\/user with signed metadata. The former makes it impossible for the attacker to set the cookie, the latter ensures the attacker doesn’t know a valid value to set it to.\\n\\nNote that signing the cookies or tokens is unnecessary and ineffectual, unless it is binding the token to a user: an attacker that\u2019s cookie tossing can otherwise obtain a valid signed pair by logging into the website themselves and then use that for the attack.\\n\\nThis countermeasure turns a cross-origin forgery problem into a cross-origin leak problem: if the attacker can obtain a token from a cross-origin response, it can forge a valid request.\\n\\nThe token in the HTML body should be masked as a countermeasure against the BREACH compression attack.\\n\\nThe primary issue with CSRF tokens is that they require developers to instrument all their forms and other POST requests.\\n\\n### Origin header\\n\\nBrowsers send the source of a request in the Origin header, so CSRF can be mitigated by rejecting non-safe requests from other origins.\\n\\nThe main issue is knowing the application\u2019s own origin. One option obviously is asking the developer to configure it, but that\u2019s friction and might not always be easy (such as for open source projects and proxied setups).\\n\\nThe closest readily available approximation of the application\u2019s own origin is the Host header. This has two issues:\\n\\n 1. it may be different from the browser origin if a reverse proxy is involved;\\n 2. it does not include the scheme, so there is no way to know if an `http:\/\/` Origin is a cross-origin HTTP\u2192HTTPS request or a same-origin HTTP request.\\n\\n\\n\\nSome older (pre-2020) browsers didn\u2019t send the Origin header for POST requests.\\n\\nThe value can be `null` in a variety of cases, such as due to `Referrer-Policy: no-referrer` or following cross-origin redirects. `null` must be treated as an indication of a cross-origin request.\\n\\nSome privacy extensions remove the Origin header instead of setting it to `null`. This should be considered a security vulnerability introduced by the extension, since it removes any reliable indication of a browser cross-origin request.\\n\\n### SameSite cookies\\n\\nIf authentication cookies are _explicitly_ set with the SameSite attribute Lax or Strict, they will not be sent with non-safe cross-site requests.\\n\\nThis is, by design, not a cross-origin protection, and it can\u2019t be fixed with the `__Host-` prefix (or Secure attribute), since that\u2019s about who can set and read cookies, not about where the requests originate. (This difference is reflected in the difference between Scheme-Bound Cookies and Schemeful Same-Site.) The risk of same-site HTTP origins is still present, too, in browsers that don’t implement Schemeful Same-Site.\\n\\nNote that the rollout of SameSite Lax by default has mostly failed due to widespread breakage, especially in SSO flows. Some browsers now default to Lax-allowing-unsafe, while others default(ed) to None for the first two minutes after the cookie was set. These defaults are not effective CSRF countermeasures.\\n\\n### Non-simple requests\\n\\nAlthough CORS is not designed to protect against CSRF, \u201cnon-simple requests\u201d which for example set headers that a simple `\\u003cform\\u003e` couldn\u2019t set are preflighted by an OPTIONS request.\\n\\nAn application could choose to allow only non-simple requests, but that is fairly limiting precisely because \u201csimple requests\u201d includes all the ones produced by `\\u003cform\\u003e`.\\n\\n### Fetch metadata\\n\\nTo provide a reliable cross-origin signal to websites, browsers introduced Fetch metadata. In particular, the Sec-Fetch-Site header is set to `cross-site`\/`same-site`\/`same-origin`\/`none`3 and is now the recommended method to mitigate CSRF.\\n\\nThe header has been available in all major browsers since 2023 (and earlier for all but Safari).\\n\\nOne limitation is that it is only sent to \u201ctrustworthy origins\u201d, i.e. HTTPS and localhost. Note that this is not about the scheme of the initiator origin, but of the target, so it is sent for HTTP\u2192HTTPS requests, but not for HTTPS\u2192HTTP or HTTP\u2192HTTP requests (except localhost\u2192localhost). If Sec-Fetch-Site is missing, a lax fallback on Origin=Host is an option, since HTTP\u2192HTTPS requests are not a concern.\\n\\n## Protecting against CSRF in 2025\\n\\nIn summary, to protect against CSRF applications (or, rather, libraries and frameworks) should reject cross-origin non-safe browser requests. The most developer-friendly way to do so is using primarily Fetch metadata, which requires no extra instrumentation or configuration.\\n\\n 1. Allow all GET, HEAD, or OPTIONS requests.\\n\\nThese are safe methods, and are assumed not to change state at various layers of the stack already.\\n\\n 2. If the Origin header matches an allow-list of trusted origins, allow the request.\\n\\nTrusted origins should be configured as full origins (e.g. `https:\/\/example.com`) and compared by simple equality with the header value.\\n\\n 3. If the Sec-Fetch-Site header is present:\\n\\n 1. if its value is `same-origin` or `none`, allow the request;\\n 2. otherwise, reject the request.\\n\\nThis secures all major up-to-date browsers for sites hosted on trustworthy (HTTPS or localhost) origins.\\n\\n 4. If neither the Sec-Fetch-Site nor the Origin headers are present, allow the request.\\n\\nThese requests are not from (post-2020) browsers, and can\u2019t be affected by CSRF.\\n\\n 5. If the Origin header\u2019s host (including the port) matches the Host header, allow the request, otherwise reject it.\\n\\nThis is either a request to an HTTP origin, or by an out-of-date browser.\\n\\n\\n\\n\\nThe only false positives (unnecessary blocking) of this algorithm are requests to non-trustworthy (plain HTTP) origins that go through a reverse proxy that changes the Host header. That edge case can be worked around by adding the origin to the allow-list.\\n\\nThere are no false negatives in modern browsers, but pre-2023 browsers will be vulnerable to HTTP\u2192HTTPS requests, because the Origin fallback is scheme-agnostic. HSTS can be used to mitigate that (in post-2020 browsers), but note that out-of-date browsers are likely to have more pressing security issues.\\n\\nFinally, there should be a tightly scoped bypass mechanism for e.g. SSO edge cases, with the appropriate safety placards. For example, it could be route-based, or require manual tagging of requests before the CSRF middleware.\\n\\nGo 1.25 introduces a CrossOriginProtection middleware in `net\/http` which implements this algorithm.\\n\\nThank you to Roberto Clapis for helping with this analysis, and to Patrick O’Doherty for setting in motion and testing this work. For more, follow me on Bluesky at @filippo.abyssdomain.expert or on Mastodon at @filippo@abyssdomain.expert.\\n\\n## The picture\\n\\nBack to Rome photoblogging. This was taken from the municipal rose garden, which opens for a couple weeks every spring and fall.\\n\\n\\n\\nThis work is made possible by Geomys, my Go open source maintenance organization, which is funded by Smallstep, Ava Labs, Teleport, Tailscale, and Sentry. Through our retainer contracts they ensure the sustainability and reliability of our open source maintenance work and get a direct line to my expertise and that of the other Geomys maintainers. (Learn more in the Geomys announcement.)\\n\\nHere are a few words from some of them!\\n\\nTeleport \u2014 For the past five years, attacks and compromises have been shifting from traditional malware and security breaches to identifying and compromising valid user accounts and credentials with social engineering, credential theft, or phishing. Teleport Identity is designed to eliminate weak access patterns through access monitoring, minimize attack surface with access requests, and purge unused permissions via mandatory access reviews.\\n\\nAva Labs \u2014 We at Ava Labs, maintainer of AvalancheGo (the most widely used client for interacting with the Avalanche Network), believe the sustainable maintenance and development of open source cryptographic protocols is critical to the broad adoption of blockchain technology. We are proud to support this necessary and impactful work through our ongoing sponsorship of Filippo and his team.\\n\\n* * *\\n\\n 1. Abuse of the ambient authority of network position, often through DNS rebinding, is being addressed by Private Network Access. The rest of this post will focus on abuse of cookie authentication. \u21a9\\n\\n 2. This is why API traffic generally doesn\u2019t need to be protected against CSRF. If it looks like it\u2019s not from a browser, it can\u2019t be a CSRF. \u21a9\\n\\n 3. `none` means the request was directly user-initiated, e.g. a bookmark. \u21a9”,”published”:”2025-08-13T15:50:33″,”modified”:”2025-08-13T15:50:33″,”type”:”filippoio”,”title”:”Cross-Site Request Forgery”,”source”:””,”references”:””,”id”:”FILIPPOIO:B8BDB7A12AA1B9C0253DEFB4C8A31A86″,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/words.filippo.io\/csrf\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2025-08-13T18:03:46″,”description”:”Cross-Site Request Forgery (CSRF) is a confused deputy attack where the attacker causes the browser to send a request to a target using the ambient…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,162,13,33,7,11,5],"class_list":["post-10639","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-filippoio","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n