SameSite cookies: stop other sites from riding your visitor's login

The threat

When a logged-in visitor is on another website, that site can quietly make requests to yours: a hidden form that auto-submits, an image tag pointing at one of your endpoints, a background fetch. If your session cookie has no SameSite attribute, the browser cheerfully attaches it to those cross-site requests, so your server sees a fully authenticated call and does what it is told. That is cross-site request forgery (CSRF): the attacker never sees the cookie, they just borrow the visitor’s logged-in browser to act as them.

The SameSite attribute tells the browser when a cookie is allowed to leave on a cross-site request. Set it, and a request that originated on someone else’s page no longer carries your visitor’s session, so the forged action arrives logged out and gets rejected. Modern browsers default an unset cookie to Lax, but the scanner still flags the absence: older browsers do not apply that default, and relying on an unstated default instead of declaring your intent is exactly the kind of gap that breaks quietly.

The exact fix

Add SameSite=Lax to the Set-Cookie header. A hardened session cookie looks like this:

Set-Cookie: sid=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

Pick the value that matches how your site is used:

• SameSite=Lax (recommended default). The cookie rides along when the visitor clicks a link to your site (a top-level navigation), but not on cross-site form posts, iframes, or background requests. This blocks CSRF while keeping normal inbound links working.
• SameSite=Strict. The cookie is withheld on every cross-site request, including a plain link from an email or another site, so those arrive logged out. Good for sensitive, state-changing flows (admin panels, money movement); slightly less friendly for general navigation.
• SameSite=None; Secure. Sends the cookie on all cross-site requests. Use it only for a genuine cross-site need (an embedded widget on other domains), and note that None is invalid without Secure.

Express.

res.cookie('sid', token, {
  sameSite: 'lax',    // or 'strict' for sensitive flows
  secure: true,
  httpOnly: true,
})

PHP (set params before session_start()).

session_set_cookie_params([
    'path'     => '/',
    'secure'   => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);
session_start();

• Any other stack: the aim is the same, get an explicit SameSite=Lax (or Strict) onto the session cookie’s Set-Cookie header.

SameSite is strong, but it is not the whole CSRF story. It is the cheapest, highest-leverage layer; for state-changing endpoints, keep your anti-CSRF tokens too. Defense in depth, not either-or.

Verify it

curl -sI https://yourdomain.com/login | grep -i set-cookie

You want an explicit SameSite=Lax (or SameSite=Strict) in the Set-Cookie attributes. A correct result names the value outright, rather than leaving the browser to guess a default.

Proof

The ApeCyber scanner reads the Set-Cookie header on a normal request, from the outside, touching nothing, and flags a session cookie that never declares SameSite. Declaring it is the cheapest CSRF hardening there is, and it is part of the same header discipline that carried apecyber.com and dev3lop.com to A / 100. About five minutes, a clean −4 off the posture score.