TL;DR
A Microdot maintainer replaced a token-based CSRF plan with a simpler method that relies on the browser-sent Sec-Fetch-Site header, with an Origin-header fallback for older clients. The change follows community discussion and an update to the OWASP CSRF guidance that recognizes fetch-metadata approaches as an alternative.
What happened
The sole maintainer of the Microdot web framework began implementing CSRF protection and initially worked on a token-based solution. After encountering community discourse and examples across Go, Ruby and Flask ecosystems, they implemented a “modern” alternative that rejects cross-site requests by inspecting the Sec-Fetch-Site header, which browsers set automatically. Because some browsers (notably older Safari versions) may not include that header, Microdot uses the Origin header as a fallback and ties allowed origins to the framework’s existing CORS configuration. The implementation also exposes an allow_subdomains option; by default Microdot blocks same-site requests from sibling subdomains. The developer kept a token-based double-submit implementation available if needed, and noted that OWASP’s CSRF guidance was updated to list the fetch-metadata approach as an acceptable alternative.
Why it matters
- Reduces implementation complexity by avoiding anti-CSRF tokens and hidden form fields in many cases.
- Relies on browser-controlled headers that cannot be spoofed by client-side JavaScript.
- Compatibility gaps (older browsers, non-browser clients) mean fallback strategies or policy choices are still necessary.
- Frameworks and standards bodies are actively re-evaluating accepted CSRF defenses, which affects library defaults and developer guidance.
Key facts
- Sec-Fetch-Site is a browser-set header with values same-origin, same-site, cross-site, and none.
- Because JavaScript cannot set Sec-Fetch-Site, servers can treat its value as coming from a browser and use it to block cross-site requests.
- Most browsers implemented the header between 2019 and 2021; Safari added it in 2023.
- When Sec-Fetch-Site is absent, Microdot falls back to using the Origin header to determine request source.
- Comparing Origin to Host is nontrivial because Origin includes scheme and Host can be modified by proxies.
- Microdot exposes an allow_subdomains option; default is False, so requests from sibling subdomains are blocked by default.
- Filippo Valsorda is credited in community discussion for proposing and implementing this fetch-metadata approach in the Go ecosystem.
- OWASP’s CSRF Cheat Sheet was updated (as of December 24, 2025) to list the fetch-metadata method as an alternative to token-based defenses.
What to watch next
- OWASP’s final guidance and wording around fetch-metadata vs token-based CSRF defenses (the author said they are monitoring it).
- Adoption by other web frameworks and libraries following the Flask issue and community discussions.
- Impact on users of older browsers and non-browser HTTP clients; whether projects require fallbacks or block such requests outright.
Quick glossary
- CSRF (Cross-Site Request Forgery): An attack that tricks a user’s browser into making unwanted requests to a site where the user is authenticated.
- Sec-Fetch-Site: A browser-provided HTTP header indicating the relationship between the origin of a request and the target site (e.g., same-origin, cross-site).
- Origin header: An HTTP header that includes the scheme, hostname, and port of the request’s origin; often used to determine where a request originated.
- Fetch Metadata: A set of browser-sent headers, including Sec-Fetch-Site, that servers can use to make decisions about the context of requests.
Reader FAQ
Does this mean anti-CSRF tokens are obsolete?
Not universally — the source says fetch-metadata is listed as an alternative by OWASP and was implemented in Microdot, but token-based fallbacks are still available if needed.
Can an attacker forge Sec-Fetch-Site or Origin headers from JavaScript?
According to the source, Sec-Fetch-Site is a restricted header that cannot be set from JavaScript, so its value is treated as reliable; Origin is also browser-controlled.
Will older browsers be blocked?
The developer used Origin as a fallback because some browsers (notably older Safari) lacked Sec-Fetch-Site; rejecting requests without the header is possible but would block older clients—further policy choices are required.
How are subdomain requests handled?
Microdot adds an allow_subdomains option and defaults to False, meaning requests from sibling subdomains are blocked unless explicitly allowed.
CSRF Protection without Tokens or Hidden Form Fields Posted by on December 21, 2025 under A couple of months ago, I received a request from a random Internet user to…
Sources
- CSRF protection without tokens or hidden form fields
- Modern CSRF Protection Using `Sec-Fetch-Site` Header
- A modern approach to preventing CSRF in Go
Related posts
- Who Watches the Waymos? YouTuber Vincent Woo Says He Tracks Waymo Vehicles
- Who Watches the Waymos? I Do — Video by Vincent Woo (YouTube, 2025)
- Why Quake’s Running Speed Was Intentionally Reduced During Development