A Lax Cookie Is Not a CSRF Token

The SameSite cookie attribute is a useful browser-side control. It limits when cookies are attached to cross-site requests. It is also easy to treat as a complete anti-CSRF design, especially when a framework silently defaults a session cookie to Lax. That treatment leaves gaps in applications that change state through top-level navigation or expose cookie behavior through multiple sites.

Same-site and same-origin are different

The cookie specification compares sites, which are derived from the registrable domain and scheme, not origins, which also include host and port. A page on app.example.com and a page on login.example.com may be same-site while remaining different origins. A cookie policy based on "same-site" therefore does not automatically protect an endpoint from another host in the same organizational domain.

SameSite=Lax sends cookies for some top-level navigations and same-site requests. It blocks many cross-site subresource requests, but it is not a rule that all unsafe methods are protected. An application can still expose a state-changing flow through a top-level GET, a redirect, or a site relationship the designer did not include in the threat model.

Use the cookie mode as one layer

MDN recommends Strict where the application can tolerate it, or Lax as a practical default. None requires Secure in modern browser behavior and should be reserved for a documented cross-site embedding need. HttpOnly protects the cookie from ordinary script access, but it does not stop a browser from sending the cookie when the request conditions allow it.

The server still needs a request-authentication strategy for sensitive operations. That can include a synchronizer token, an origin or referrer check with a documented fallback, or a design that requires an explicit user action and a fresh authorization check. Choose the control that matches the application's navigation and embedding requirements.

Test the real browser path

Create two test sites and try the operations that matter: a form POST from another site, a top-level GET that a server treats as a state change, an iframe workflow, and a redirect chain. Inspect the Set-Cookie header and the browser's cookie state. Do not rely only on a command-line client, which does not implement the browser's site rules.

Verify the result from both the application and the authorization layer. A request that reaches the server with a valid session is not automatically an authorized action. A request that arrives without a cookie should fail at the first authentication check, and a request with a cookie from a sibling site should not bypass the server-side policy.

Deployment details

Set cookie attributes consistently across environments. Check that proxies do not rewrite Set-Cookie, that TLS termination preserves Secure, and that a subdomain migration does not change the registrable site boundary. Inventory cookies used by authentication, preferences, and embedded tools; a single unprotected preference cookie can leak information even when the session cookie is strict.

Use a small test matrix in the release checklist. Include a cross-site navigation, a cross-site form submission, an embedded iframe, and a same-site sibling host. Record the browser version and the observed header. If the application depends on a top-level callback, test whether Lax still allows the cookie and whether the callback can be abused to change state.

SameSite reduces a class of browser-driven requests. CSRF protection remains a property of the endpoint, its authorization logic, and the workflow that accepts state changes. The two controls should be reviewed together.

References

• MDN CSRF guidance
• MDN HTTP cookie guide