Samesite is the browser security mechanism that determine when a website’s cookies are included in the requesting originating from another websites. Since 2021 the chrome makes the lax as the default for samesite restrictions.

What is the site in context of samesite

A site is defined as the top level domain (TLD), usually something like .net or .com. When determining whether a request is same-site or not, the URL schema also takes into consideration. This means that a link from http://mydomain.com to https://mydomain.com considered or treated as the cross-site by most of the browsers.

![[Pasted image 20250628001240.png]]

Site vs Origin

The difference between the site and the origin is their scope. The site describes multiple domains whereas the origin only describes one. It not use these words interchangeably which makes serious security implications.

  • So when we talk about the like site it is the combination of scheme, TLD and TLD+1. so it will have multiple subdomains.
  • Whereas the origin the combination of ip and port which makes unique and single one.

![[Pasted image 20250628001815.png]]

Understanding the working of SameSite

  • Usually before the SameSite mechanism is introduced the browsers send the cookies along with the request to the domain that issued them. Even the request was send or triggered by a third party malicious website. This makes the user vulnerable to csrf attacks.
  • SameSite works by enabling the browsers and websites owners limiting the cross requesting if any should only include the specific cookies which makes reduce the user’s exposure to the csrf attacks.
  • Even the users open the malicious code and make trigger to the malicious code it will need a authentication session cookie to be included to the request otherwise the request will be rejected by the server.

  • In SameSite restriction they are three level of restriction:

    • Strict
    • Lax
    • None
  • To configure the restriction level of the cookie it must be done by developer manually while setting the cookie to the response.
Set-Cookie: session=0F8tgdOhi9ynR1M9wa3ODa; SameSite=Strict
  • Although it offers some protection against the CSRF attacks, but it doesn’t gives guarantee it always depends on the developer written code.

SameSite=Strict

  • If the cookie is set to the strict the browser will not allow to add the cookies to the cross site requests. Simply the browser allows the cookies which are related to the site which is present in the address bar.
  • This is recommended that when we performing some actions like accessing pages or request where we need to allow the authenticated users only.
  • Although it is the most secure option but it may effects the user experience when their is a cross site request is desirable.

    SameSite=Lax

  • Lax is another restriction level where browser add the cookie to the cross site requests but that request must be meet the following criteria

    • The request method must be GET. The browser don’t add the cookie to the cross site requests where their requested method is POST because usually we use the POST method to modify or insert data.
    • The request resulted from a top level navigation by the user, such as clicking on link. Which means the request must be initiated by the user not by background requests like scripts, iframe..etc

SameSite=None

  • Making the restriction none remove all these restriction which means the browser add the cookies to the request which run in the background by the third party websites.
  • Expect chrome most of the browsers the default samesite restriction is none.
  • There is legitimate reason for it most websites uses the third party scripts need to be run like the website depends on the third party to do some action. Like OAuth we need the add the cookie to the script inside the browser to login. Even thought the cookie is encrypted and added the bearer it still makes the unique identifies if the website vulnerable their is change exposing to csrf attacks.
  • Its better to add the secure to the cookies when we are using SameSite=None makes the cookie to be encrypted over HTTPS.

Bypassing the SameSite Lax restriction using GET method

  • In practice, many poorly designed servers don’t strictly enforce the expected HTTP method. Even if an endpoint is intended for POST form submissions, the server may still accept a GET request if not properly validated.
  • When a cookie is set with SameSite=Lax (which is the default in most browsers), the browser allows top-level GET navigation to include the cookie. This means a CSRF attack can still succeed if the targeted endpoint accepts GET requests.
  • And as we know the rule 2 where the request should be top level navigation the following makes to satisfies the rule 2.
<script>
document.location = "https://somewebsite.com/account/transfer-payment?recipient=hacker&amount=1000000"
</script>
  • Some web frameworks (like Ruby on Rails, Laravel, Express, etc.) allow overriding the HTTP method using parameters like _method=DELETE or _method=POST. If the server doesn’t validate this properly, an attacker can manipulate a GET request to behave like a POST.

Bypassing the SameSite Strict using the Third party gadgets

  • If a cookie set with the SameSite=Strict attribute browser won’t allow any type of cross site requests.

  • Redirect gadgets (especially client-side) allow attackers to bypass SameSite=Strict by triggering a second, same-site request.

  • A client-side redirect (e.g., using window.location.href) is interpreted by the browser as a new, first-party navigation, so SameSite=Strict cookies are included.

  • However, a server-side redirect (via HTTP 302) still causes a cross-site chain, and depending on the browser’s implementation, cookies may or may not be sent. So, client-side redirect gadgets are more reliably effective for SameSite=Strict bypass.