A modern approach to preventing CSRF in Go
The code he provides doesn't compile and needs to be changed like so:
--- main_before.go 2025-10-15 09:56:16.467115934 +0200 +++ main.go 2025-10-15 09:52:14.798134654 +0200 @@ -13,8 +13,10 @@ slog.Info("starting server on :4000") + csrfProt := http.NewCrossOriginProtection() + // Wrap the mux with the http.NewCrossOriginProtection middleware. - err := http.ListenAndServe(":4000", http.NewCrossOriginProtection(mux)) + err := http.ListenAndServe(":4000", csrfProt.Handler(mux)) if err != nil { slog.Error(err.Error()) os.Exit(1)On a side note Alex books are a breath of fresh air for someone who is learning. They are always updated to the latest version of Go and if there is something new the old code base is updated and the new concepts introduced while you are being notified and send the new version of the book.
I never seen that before, all the other learning sources that I have are just abandoned, often there will be something that brakes and you have to spend good amount of time to figure out how to fix it, which can just discourage you to go on.
Kudos to Alex that is how it should be done.
Are CSRF attacks that common nowadays though? Even if your app is used by the 5% of browsers that don’t set the Origin header the chances of that being exploited are even more miniscule. Besides, most webdevs reach for token-based auth libraries before even knowing how to set a cookie header.
I deeply appreciate this thorough review of CSRF protection via headers. I've been looking into the topic to see if I can get rid of csrf tokens, and it seems like I can now - if I ignore/don't care about the 5% of browsers that don't support the required headers.
It makes me wonder though - most browser APIs top out around 95% coverage on caniuse.com. What are these browsers/who are these people...? The modern web is very capable and can greatly simplify our efforts if we ignore the outliers. I'm inclined to do so. But am also open to counterarguments
CSRF: Cross-Site Request Forgery
From https://developer.mozilla.org/en-US/docs/Web/Security/Attack...
In a cross-site request forgery (CSRF) attack, an attacker tricks the user or the browser into making an HTTP request to the target site from a malicious site. The request includes the user's credentials and causes the server to carry out some harmful action, thinking that the user intended it.
Alex has two books that I can’t recommend more. Let’s Go and Let’s Go Further really cemented Golang for me.
Do we still need _HOST?
Killing all the fun.
Remember when you could trick a colleague into posting in Twitter, Facebook... by just sending a link?
CSRF fixes are great for security - but they've definitely made some of the internet's harmless mischief more boring
Enforcing TLS 1.3 seems like a roundabout way to enforce this. Why not simply block requests that don’t have an Origin/Sec-Fetch-Site header?
Would have like to have seen a complete working example at the end that addresses all the concerns
undefined
Do most languages have good support for TLS 1.3 as the client?
rails solved this a while ago ;)
"cop" as an abbreviation for "cross-origin protection" is delightful
[dead]
I would never rely on headers such as "Sec-Fetch-Site"; having security rely on client generated (correct) responses is just poor security modelling (don't trust the client). I'll stick to time bounded HMAC cookies, then you're not relying on client properly implementing any headers and it will work with any browser that supports cookies.
And having TLS v1.3 should be a requirement; no HTTPS, no session, no auth, no form (or API), no cookie. And having HSTS again should be default but with encrypted connections and time bounded CSRF cookies the threat window is very small.