Today, I was going through the process of making sure my server is protected against CSRF attacks, and I was wondering why there is not just a SameOrigin flag that I can set on my Cookies. In much the same way that you can set HTTPOnly or Secure on cookies, I think there should be a SameOrigin flag which would only send the cookie if the browser was currently on the same website as what the cookie was set on.

Wouldn't this be an elegant solution to solving CSRF attacks? You could also implement it in a backwards compatible way where cookies that don't have SameOrigin set are just treated the way that cookies have always behaved.

  • 1
    Could you elaborate on "Same Origin" for cookies? Cookies are inherently same origin - they are sent only to the domain/sub-domain they were set by. And who is setting the same origin flag here? The client or the application server?
    – katrix
    Commented Jan 12, 2017 at 20:36
  • 1
    Yes, cookies are sent TO the domain they were set by. However, I want the cookie to only be sent FROM the domain they were set by as well. The same origin flag would be set by the application server and would be stored in the browser with this flag. The browser would need to respect this flag and not send site A's cookies to site A's server via site B.
    – satnam
    Commented Jan 12, 2017 at 20:40
  • 1
    @satnam Cookies aren't sent by a domain. They are sent by an HTTP client, typically a browser, which is inherently domain-less. You could, in practice, simulate what your describing by dropping or ignoring any sensitive cookies if the referer header is from another domain, but this is not fool-proof either, for instance, a referer is not set if the referer is an HTTPS URL and referee is an HTTP URL, or if the client strips referers for privacy reasons.
    – Xander
    Commented Jan 12, 2017 at 21:10
  • 2
    There is a draft proposal for "same site cookies". I think only Chrome implements them just now.
    – paj28
    Commented Jan 12, 2017 at 21:16
  • 1
    Also of note: site != origin. See web.dev/same-site-same-origin
    – jub0bs
    Commented Feb 4, 2021 at 18:23

3 Answers 3


It is a good idea, and as @paj28 pointed out in the comments, there is already an RFC draft for SameSite cookies.

One downside that is mentioned in the draft:

Consider the scenario in which a user reads their email at MegaCorp Inc's webmail provider "https://example.com/". They might expect that clicking on an emailed link to "https://projects.com/secret/project" would show them the secret project that they're authorized to see, but if "projects.com" has marked their session cookies as "SameSite", then this cross-site navigation won't send them along with the request. "projects.com" will render a 404 error to avoid leaking secret information, and the user will be quite confused.

Basically, a strict SameOrigin cookie would break links to backend components.

The draft also proposes a lenient mode which would send cookies on GET requests across sites, but it is a common problem that many applications do not follow restful, but instead have GET requests that change server state.

Another problem is that applications will still need to implement their own CSRF protection for all those users not using up-to-date cookies, so the extra development costs of correctly configuring SameOrigin cookies may not be worth it for some developers.

  • The projects.com problem is something ive not considered, but is a really useful thing to be aware of. Thanks!
    – hiburn8
    Commented Aug 20, 2020 at 9:55

The SameSite policy still misses the mark for trustworthy cross-domain services.

Say I am browsing a site at firstparty.com which loads a script from mytrustedpartner.com to provide valuable functionality to my site.

mytrustedpartner.com could be some sort of widget that uses cookies to store state about the user that persists while the users continues to browse pages at firstparty.com

mytrustedpartner.com only cares about the state associated with the user at firstparty.com

If someothersite.com also loads the mytrustedpartner.com script, and the same user visits both firstparty.com and someothersite.com - mytrustedpartner.com does not want all the cross-site cookie information! mytrustedpartner.com wants to see separate cookie information, depending if the user is browsing at firstparty.com or someothersite.com

The SameSite policy above does not allow this, what-so-ever. SameSite cookies will completely drop any Set-Cookie header in which the origin site and request site do not match.

This is why we desperately need a SameOrigin policy. SameOrigin would allow 3rd party services to be treated as first-party players, without information leakage or invasive tracking.


Cookies are inherently same-origin, in the sense cookies are sent by the browser only to the origin (and possible sub-domains) that set the cookie in the first place. Referring to the information on your comment, cookies are only between the browser and a site. The reason a CSRF attack is successful even though the originating request is from a different domain is because of where the request is going TO, not where its coming FROM.

About backwards compatibility, a non-same-origin cookie could be one that could be set by or sent to other domains. That would be dangerous since you wouldn't want evil.com to receive google.com cookies.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .