SameSite and XSSI

What is here:

  1. http-equiv
  2. SameSite cookie

Short review of meta http-equiv

<meta http-equiv="<>" content="<>">

The http-equiv attribute provides an HTTP header for the information/value of the content attribute.

The http-equiv attribute can be used to simulate an HTTP response header.

So, basically, using a HTML directive like:

<meta http-equiv="set-cookie" content="id=12345; SameSite=Strict">

is equivalent to:

Set-Cookie: id=12345; SameSite=Strict;

sent by the server.

SameSite cookie

The aims of this cookie attribute are:

  • prevent cross origin timing attacks:

    ( and

  • prevent cross origin script inclusion (XSSI):

    “XSSI is a fancy way of saying: you are including in your program, someone elses code; You don’t have any control over what is in that code, and you don’t have any control over the security of the server on which it is hosted.

    That script will run in my webapp with the same level of trust as any of my own javascript code. It will have access to the the full page content and DOM, it will be able to read all my app’s cookies and read the users keypresses and mouse movements, and everything else that javascript can do.

    If my mate dave, then decides to put something malicious in his cool widget (say, a sniffer/keylogger that sends all the user’s cookies, form data and keypresses to his server) then I won’t necessarily know. Also, the security of my app now depends on the security of dave’s server. If dave’s server gets compromised and coolwidget.js is replaced by the attacker, i again won’t necessarily know and the malicious code will run as part of my app. “(

  • prevent CSRF: SameSite cookies are only sent if the site the request originated from is in the same origin as the target site (in strict mode for GET and POST, in lax mode only for POST requests).

    NOTE: The cookies are, as also with cross-site request forgery (CSRF), included when requesting a resource from a different host.

SameSite cookie flag can be strict or lax:

  • strict: will prevent the cookie from being sent by the browser to the target site in all cross-site browsing context. A bank website however most likely doesn’t want to allow any transactional pages to be linked from external sites so the strict flag would be most appropriate here. It can affect negatively the user experience, if a user click on a FB profile page on a site diverse than he will see error 404.
  • lax: the browser is sending the cookie if the user clicks on a top level URL

HTTP Headers:

Set-Cookie: CookieName=CookieValue; SameSite=Lax;
Set-Cookie: CookieName=CookieValue; SameSite=Strict;

Let’s make some examples:

Many times the browser will send some requests cross origin when the page is loaded, could it be advertisements, tracking, analitycs, Facebook like buttons and so more. Along with these requests, the cookies present in the victim browser that belong to that domains will also be sent.

This is how Third-Party can track their users.

With SameSite lax only TOP LEVEL NAVIGATION allow requests to include cookies.

Basically, they don’t change the URL in your address bar. Because these GET requests do not cause a TOP LEVEL navigation, thus cookies set to Lax won’t be sent with them.

Should i use GET or POST?

  • When the parameters are carried by GET, they stay in the browser history. They also will be placed in server logs and the Referrer header in the request made toward third parties.
  • Another reason for not using GET requests is that cookies set to Lax are still sent along with GET requests, giving attackers another opportunity to exploit users.
  • Lastly, exploiting a CSRF vulnerability by using GET is much easier. To exploit a CSRF vulnerability in a form using GET, an attacker does not have to own a site. He can inject this payload into a forum message, post comment or image tag.

GOOD reference for SameSite explanation

Problems with SameSite

Blocking all third party cookies could make the browser experience very poor.


		Setting the "SameSite" attribute in "strict" mode provides robust
   defense in depth against CSRF attacks, but has the potential to
   confuse users unless sites' developers carefully ensure that their
   session management systems deal reasonably well with top-level

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

	   Developers can avoid this confusion by adopting a session management
   system that relies on not one, but two cookies: one conceptualy
   granting "read" access, another granting "write" access.  The latter
   could be marked as "SameSite", and its absence would provide a
   reauthentication step before executing any non-idempotent action.
   The former could drop the "SameSite" attribute entirely, or choose
   the "Lax" version of enforcement, in order to allow users access to
   data via top-level navigation.

Differences between XSSI and XSS? Read here