Open meech-ward opened 7 months ago
Are you making any requests from client on subdomains?
No. One domain only. I'm just assuming that everyone would want to the behaviour of lax but it defaults to none
My bad, I didn't know it was defaulting to none!
I think the current chrome standard is if no sameSite attribute is set, it defaults to Lax?
I just tested it locally once using this package and another using a basic api route handler - in both cases the sameSite attribute is None!
Tested on Vercel too, huge CSRF risk if someone forgets to define!!
Actually, I must've been testing locally where I got it working (as both domains were localhost).
I tried a lot and NextJs actually adds a 'HostOnly: True' cookie attribute which prevents any CSRF, it only allows cookies to be sent between the same host!
They made it very difficult to send cookies between two different domains, I tried adding CORS accept * headers too and still couldn't get the cookies to send!
UPDATE: cross origin resource sharing of cookies in 2024 will require CORs option prefetching, setting a sameSite=None Secure cookie no longer allows a cookie to be sent with a CORs requests unless evildomain.com is part of an allowlist which is dynamically defined in mydomain.com's Access-Control-Allow-Origin - only one domain can be recognised in the response by browser.
After some testing, sameSite=None Secure acts the same as a Lax cookie, only allowed in top level navigation!
I am part of 1% of developers to supposedly experience this, but spoke to Hussein last night and he confirmed!
Check out: https://github.com/GoogleChromeLabs/samesite-examples/issues/53#issuecomment-1934670773
The article I link at the bottom of that issue explains that by mid-2024, tracking cookies or sameSite=None should be completely deprecated without setting appropriate CORs headers!
I know server actions guard against CSRF, but would it be a good idea to still add sameSite: "lax" or "strict"?