I think he means CSRF prevention hacks are dead, because, despite being the norm, adding a CSRF token in each POST request is indeed an ugly hack.

Not ugly, it's just passing a state-key around - a common practice in loads of other communication channels.

That doesn’t really fit in with modern web interfaces though. REST and GraphQL are both stateless architectures. Tracking and mutating a state on every request doesn’t fit very well with with that.

Depending on exactly what we're doing, we can work around this with crypto, right?

A token can securely prove that it was issued by the server/service, and under what conditions, without the server/service statefully tracking the token after issuing it.

I know I'm not the first to think of this, but I'm not sure how widely used this sort of technique is in practice.

That’s exactly how authentication JWTs work. They work differently from CSRF tokens though, because the CSRF token is generated for each request, not each ‘session’ (so you need much more complex server-side state management). But that said CSRF isn’t particularly relevant if you’re using a JWT in the Authorization header. CSRF attacks the fact that browsers will use cookies to automatically authenticate requests. If you’re not using cookies for authentication, and adding a JWT to the headers instead, then that automatic authentication doesn’t occur. Correct me if I’m wrong, but I’m not aware of any CSRF attack that targets Authorization headers, I believe any attack that does is just an XSS.

Well, where you store your JWT on the client? LocalStorage? Then you have probably much broader surface for an attacker.

In case of XSS you lost anyway. But with HttpOnly-Cookies the attacker can't steal your token and do everything from everywhere with your token.

XSS is a problem you have to solve no matter where you store your authentication material. If you have an XSS, then an attacker can do anything they want on your web pages. I’m not sure you’re gaining anything by saying “anything but steal the auth token”. If you store it as a cookie, now you have to solve XSS and CSRF, so I’d say that makes your attack surface broader. Especially considering front end frameworks have become very good at preventing XSS, and can’t do anything about CSRF.

When you send a PATCH request, and include a token of the object you're patching, so the system knows your using an up-to-date object? In that REST like example that hash/token on the object is the same function as CSRF-token. I see this model on APIs daily.

That sounds more like an integrity check than a CSRF control. Unless you have poor CORs settings, wouldn’t SOP prevent CSRF on PATCH endpoints anyway?

It's that too. My point (still) being that passing state keys is old, common and still in use.

This is what cookies are for. No one will be using CSRF tokens once cookies are fixed (e.g. SameSite is widely supported). "Just passing a state-key around" is not mutually exclusive with "being an ugly hack".

Having to add state to fundamentally stateless operations is not a good thing.

Being logged in is not a stateless thing. Cookies are state.

It actually is stateless. The cookie is just one part of the stateless request.