top | item 46384161

(no title)

FiloSottile | 2 months ago

SameSite doesn’t protect against same-site cross-origin requests, so you are staking your app’s security on the security of the marketing blog.

discuss

order

hn_throwaway_99|2 months ago

Thanks very much for your comment. I posted elsewhere that I felt like SameSite: Lax should be considered a primary defense, not just "Defense in depth" as OWASP calls it, but your rationale makes sense to me, while OWASP's does not.

That is, if you are using SameSite Lax and not performing state changes on GETs, there is no real attack vector, but like you say it means you need to be able to trust the security of all of your subdomains equally, which is rarely if ever the case.

I'm surprised browser vendors haven't thought of this. Like even SameSite: Strict will still send cookies when the request comes from a subdomain. Has there been any talk of adding something like a SameSite: SameOrigin or something like that? It seems weird to me that the Sec-Fetch-Site header has clear delineations between site and origin, but the SameSite header does not.

FiloSottile|2 months ago

Browser vendors have absolutely thought about this, at length.

The web platform is intricate, legacy, and critical. Websites by and large can’t and don’t break with browser updates, which makes all of these things like operating on the engine in flight.

For example, click through some of the multiple iterations of the Schemeful Same Site proposal linked from my blog.

Thing is, SameSite’s primary goal was not CSRF prevention, it was privacy. CSRF is what Fetch metadata is for.