Cookies and session hardening in the browser

The SameSite attribute controls whether a cookie is attached to requests that a different site initiated. Remember that site means scheme plus registrable domain, so https://app.cyart.io and https://blog.cyart.io are same-site, and since schemeful same-site, http://cyart.io and https://cyart.io are not.

• Strict is the strongest CSRF defence but annoying for a session cookie: a user following a link from email to your app arrives looking logged out. A common pattern is a Lax session cookie plus a Strict cookie required for sensitive actions.
• Lax blocks cross-site POSTs and subresources, which neutralises classic CSRF, while keeping inbound links working. GET endpoints that change state are still exposed: never change state on GET.
• None is for cookies that genuinely need cross-site use (embedded widgets, some SSO flows) and must be Secure.

Lax-by-default: since Chrome 80 (2020), Chromium treats cookies with no SameSite attribute as Lax. A temporary "Lax+POST" exception still sends such cookies on top-level cross-site POSTs for 2 minutes after they are set, so SSO form posts kept working. Firefox and Safari did not ship Lax-by-default, so always set SameSite explicitly rather than relying on any browser's default.

Cookies have weak integrity. A subdomain can set a cookie for the parent domain, and historically an HTTP page could overwrite a cookie a HTTPS page set. An attacker controlling sub.cyart.io can toss a sid cookie scoped to .cyart.io and fix the victim's session. Cookie name prefixes make the browser enforce rules at set time:

Set-Cookie: __Host-sid=k7Qe0m9VbX2pLr4T; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600
Set-Cookie: __Host-csrf=Zt5uYw1aQe8rN3cF; Path=/; Secure; SameSite=Strict
Set-Cookie: __Host-widget_prefs=theme%3Ddark; Path=/; Secure; SameSite=None; Partitioned

# Rejected by the browser, never stored:
Set-Cookie: __Host-sid=abc; Path=/; Secure; Domain=cyart.io     <- Domain not allowed with __Host-
Set-Cookie: __Secure-token=abc; Path=/                          <- missing Secure

Partitioned cookies (CHIPS, Cookies Having Independent Partitioned State) handle third-party embeds. A cookie with the Partitioned attribute (plus Secure) set by widget.cyart.io inside an iframe on shop.example is keyed to the pair (top-level site shop.example, cookie host). The same widget embedded on news.example gets a separate, empty jar. The embed keeps state per embedding site, but cannot be used to track a user across sites. Chrome supports it since version 114; Safari and Firefox already block or partition most third-party cookies by default, so CHIPS is the portable way to keep embedded state working.

Storage partitioning applies the same idea to everything else a third-party iframe can store: localStorage, IndexedDB, Cache Storage, service workers and BroadcastChannel are keyed by top-level site, and the HTTP cache is partitioned too. A practical consequence: a widget can no longer share login state across embedding sites through storage. It needs an explicit flow such as a top-level redirect or the Storage Access API.

window.postMessage is the sanctioned way for cross-origin windows and iframes to talk. It is safe only if both sides name the other origin. The sender passes a targetOrigin so the message is not delivered if the window has navigated somewhere else. The receiver checks event.origin exactly, and treats event.data as untrusted input.

const WIDGET_ORIGIN = "https://widget.cyart.io";
const frame = document.getElementById("billing-widget");

window.addEventListener("message", (event) => {
  if (event.origin !== WIDGET_ORIGIN) return;              // exact match: no indexOf, endsWith or regex
  if (event.source !== frame.contentWindow) return;        // and from the frame we embedded
  const msg = event.data;
  if (typeof msg !== "object" || msg === null || msg.type !== "resize") return;
  if (!Number.isInteger(msg.height) || msg.height < 0 || msg.height > 5000) return;
  frame.style.height = msg.height + "px";                  // never innerHTML or eval with message data
});

// Sending: name the receiver, never "*" for anything sensitive
frame.contentWindow.postMessage({ type: "session", csrf: csrfToken }, WIDGET_ORIGIN);

• Missing origin check means any site that can frame or open your page can drive the handler. Combined with a sink like innerHTML it is DOM XSS; with an action like "save settings" it is CSRF without cookies.
• targetOrigin: "*"** leaks the payload to whatever document is in that window now, for example after an attacker navigated the iframe away.
• Weak matching: event.origin.indexOf("cyart.io") !== -1 passes https://cyart.io.attacker.net.

Clickjacking loads your page in an invisible iframe on an attacker's page and lines up a button the victim thinks they are clicking ("Play video") over your real button ("Delete account", "Approve payment"). The victim's cookies make it an authenticated click. The defence is to tell the browser which sites may frame you.