What is SameSite-Cookie:
Same-site cookies (“First-Party-Only”) allow servers to mitigate the risk of CSRF and information leakage attacks by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain.
Same-site cookies can effectively prevent CSRF attacks. Why?
If you set the session cookie as same site, it will only be sent if a request eminates from your site. So a standard CSRF attack where the attacker lures the victim to the site http://malicious.com that posts a request to http://bank.com/transfer.php?amount=10000&reciever=evil_hacker will not work. Since malicious.com is not the same origin as bank.com, the browser will not send the session cookie, and transfer.php will execute as if the victim was not logged in.
This is very similar to how setting a X-Csrf-Token HTTP header protects you from CSRF – again there is something that is only sent if the request emminates from your domain. The same-site property turns your session cookie into a CSRF-token.
So problem solved? Well, sort of. There are some caveats:
This will only work for browsers that implements this feature. So far, very few does. Unless you want to throw everybody who uses a slightly older browser under the buss, you will still need to implement an old fashioned CSRF-token.
If you need more fine grained control, this will not be enough. If you run a system that displays untrusted user content, like a forum, you don’t want requests originating from user posts to be treated as valid. If someone posts a link to http://myforum.com/?action=delete_everything you don’t want that to delete anything just because a user clicks it. With a traditional CSRF-token, you can control exactly when it is used. With a same-site cookie, you can not.
If you have an XSS vulnerability, no CSRF protection in this world will safe you.
XSS and XSSI?
The same-site cookie does nothing to protect you from ordinary XSS attacks. If a hacker manages to fool your site to echo out script from the URL on your site it will be executed as coming from your origin (after all, it is) and thus session cookies will still be sent with all requests the injected script makes to your domain.
XSSI with an I at the end, and not XSS. The I stands for inclusion, and XSSI is related to but different from XSS. Here is a good explanation of XSSI and how it differes from XSS:
Same-site cookies protects you from XSSI, since a session cookie would not be sent with the request for the script and it would thus not return any sensitive information. However, for ordinary XSS it makes no difference.
Finally we can conclude that SameSite Cookie attribute is a best suggestion for XSSI and CORS based CSRF attacks and for those whom rely on full CSRF Protection they can simply adapt X-CSRF-Token implimentation.