This is basically saying that if you're using server actions you don't need to worry about it. But if you're using /route.tsx you'll need to protect that endpoint with CSRF manually to ensure other people aren't using (or abusing) the API endpoint as well.

CSRF is a kind of attach where you force people to send their cookie to you

so you can impersonate them

it seems that Server Actions have CSRF protection

I don't know it very well and should probably work on it at some point

but the idea of this protection is that the client brings an additional token that can't be hijacked by the attacker

It's a generic type of thing, a common source of information is the OWASP

but I deplore the lack of such information in the wild

I've written a piece to gather my limited knowledge a while ago https://www.smashingmagazine.com/2023/01/authentication-websites-banking-analogy/

Blitz.js has a solid auth system too, you could check libs like Next Auth, usually they cover stuff like that

Most of what you'll read on Stack Overflow or random posts is sadly out of touch or very vague (like many posts conflates server-server communication that is secured with headers, client-api that can be secured either with cookies or headers, and web page access that has to be secured with cookies)

It's worth noting that CSRF protection is for a very specific type of attack that is a combination of things, not just related to one cookie. You're particularly vulnerable if you don't define specific HTTP methods on your endpoints (like POST), or have CORS enabled. For example, if a bank has a /transfer endpoint that accepts GET requests and query params, I could just stick a hidden image on a website like this and process requests just as if I were the logged in user, if they have an active session (cookies).

<img src  = “https://samplebank.com/onlinebanking/transfer?amount=5000&accountNumber=425654” width=“0” height= “0”>

CSRF is basically a "one-time use" token that ensures the user is accessing the endpoint from inside the application on the same domain

@Marchy @Eric Burel Ahh thank you! I do have an auth library, using cognito and amplify which has Priority: Medium and SameSIte: strict - do you need the csrf token if you have SameSite: strict on the cookie and validate it on each api request?

With defining api endpoints, is using the next.js route like this export async function POST(request: Request) enough to only allow the post request on that route, or do you also have to check if it equals a post request too?

I think that's a bit of the grey area of "it depends"
It depends on if/how your middleware is configured, if there are matching paths, etc. Best practice would be just to not use API routes as this is kind of an escape hatch for "legacy" patterns before react 18

(weird to use the term legacy for something that's only a few years old but 😂 )

Ah thanks, time to move to server actions then 😄