Blog, COLDSURF

🌊

πŸ’»

🎧

πŸŽ₯

πŸ“–

πŸ“·

πŸ§‘πŸ»β€πŸ’»

Cookie, SameSite

This is a translation based on the article from https://seob.dev/posts/λΈŒλΌμš°μ €-쿠킀와-SameSite-속성/.

What is a Cookie?

A cookie is one of the methods for storing data in a browser.

When a browser sends a request to a server, if the server's response includes a Set-Cookie header, the browser saves the data from the Set-Cookie and refers to it as a cookie.

Set-Cookie: normal=yes

In this case, a cookie named "normal" with the value "yes" is saved. The next time the browser sends a request to the server, the cookie will be included in the request under the Cookie header, allowing the server to use it for user identification or other purposes.

Cookie: normal=yes;

Cookies are mainly used by servers to identify users. For example, a SessionID could be set via the Set-Cookie header, and the SessionID will be sent along with subsequent requests to identify which user is making the request.

Many websites implement login functionality in this way.

Setting the Domain for Cookies

Cookies can have a specific domain set to define the valid site for the cookie.

set-cookie: normal=yes; Domain=localhost

A cookie with a domain set (e.g., localhost) will only be valid for that domain. The normal cookie will be sent only for requests targeting localhost.

If no domain is specified for the cookie, the domain of the server that sent the cookie is used by default.

First-Party Cookies vs. Third-Party Cookies

Based on the domain settings, cookies are classified into First-Party Cookies and Third-Party Cookies.

<html>
  <head>
    <title>seob.dev</title>
    <meta property="og:url" content="<https://seob.dev/>" />
  </head>
  <body>
    <img src="<https://example.com/image.png>" />
  </body>
</html>

Let’s assume the HTML code above is from the seob.dev website. When you visit seob.dev, it requests the image from example.com. If the user already has a cookie for example.com, it will be sent along with the request to the server at example.com. This cookie is considered a third-party cookie because it is sent to a different domain than the one the user visited.

Third-party cookies are cookies sent to a domain different from the one the user is visiting.

If the user clicks on a link from seob.dev to example.com, any cookies sent with the request are also considered third-party cookies. The Referer will be seob.dev.

<html>
  <head>
    <title>seob.dev</title>
    <meta property="og:url" content="<https://seob.dev/>" />
  </head>
  <body>
    <!-- The cookies sent when this link is clicked are considered third-party cookies -->
    <a href="<https://example.com/>">Link</a>
  </body>
</html>

First-party cookies are simpler to understand. These are cookies sent to the same domain that the user is visiting.

The same cookie can be considered both a first-party and third-party cookie, depending on the domain of the website the user is visiting. In the example above, a cookie set on example.com would be a third-party cookie when the user visits seob.dev, but it would be a first-party cookie if the user is on example.com.

Cookies and CSRF Issues

By default, browsers (except Chrome) send cookies with every HTTP request, including requests for HTML documents, images, XHR, or form submissions.

CSRF (Cross-Site Request Forgery) is an attack that exploits this issue.

SameSite was introduced to address this problem.

SameSite Cookies

SameSite cookies are designed to address the security issues of third-party cookies by limiting the transmission of cookies in cross-site requests.

With the SameSite attribute, you can choose from three policies: None, Lax, and Strict, each with different behaviors.

  • None: This works the same way as cookies did before the introduction of SameSite. Cookies set to None will always be sent in cross-site requests, including third-party cookies. This is the least secure option, as it doesn't restrict cross-site requests.
  • Strict: The most restrictive policy. Cookies set to Strict will never be sent in cross-site requests. Third-party cookies are not sent, and only first-party cookies are allowed.
  • Lax: A more lenient policy than Strict. Cookies set to Lax will generally not be sent in cross-site requests, but there are some exceptions where they will be sent.

When Lax Cookies Are Sent

For a detailed explanation, you can read this link.

Browser Implementation of SameSite

Lax by Default

Chrome is the browser that most actively applies the SameSite attribute. Before February 2020, cookies without a SameSite attribute defaulted to None. However, with the release of Chrome 80 on February 4, 2020, the default for SameSite cookies was changed to Lax. This change affected many web services.

For more details, you can read here.

Secure Cookie Policy

For cookies with SameSite=None, the cookie must also be a Secure cookie.

A Secure cookie is only sent over HTTPS (i.e., encrypted requests).

Currently, Chrome is the only browser that enforces this policy. Therefore, when setting a SameSite=None cookie in Chrome, the cookie must be marked as Secure, otherwise, the cookie will not be set properly.

set-cookie: same-site-none (non-secure)=yes; SameSite=None
← Go home