Session-like cookie does not specify SameSite=Lax or SameSite=Strict
ShipReady found a session-like cookie response that did not specify SameSite=Lax or SameSite=Strict.
Why it matters
SameSite is a cookie attribute that an application can set deliberately for its intended request flows. This finding helps identify session-like cookie responses whose observed attribute is absent, None, or another value outside ShipReady's Lax and Strict policy.
How ShipReady detects it
What it inspects
ShipReady reads individual Set-Cookie values from the final fetched response. It considers only names matching its session/auth naming heuristic and excludes names with CSRF/XSRF, callback, redirect, preference, locale, consent, or theme markers.
What triggers a finding
The rule triggers when a qualifying, parseable cookie has no SameSite value or has a value other than Lax or Strict. SameSite=None therefore also triggers this rule.
What the evidence shows
The captured response set a cookie whose name matched ShipReady's session-like heuristic and whose parsed SameSite attribute did not meet the scanner's Lax-or-Strict condition. The report includes the cookie name, never its value.
Limits of this check
The name heuristic does not establish that a cookie authenticates a user. ShipReady does not execute browser code, test cross-site requests, determine browser default SameSite handling, or confirm that a cookie persisted in browser storage. It observes only parseable Set-Cookie values on the final fetched response, not intermediate redirect responses or every application route.
How to fix it
Choose a SameSite policy for the cookie's intended flow
Set SameSite=Lax or SameSite=Strict where that policy fits the cookie's intended use, then test the flows that rely on the cookie.
If the application intentionally needs SameSite=None, assess that configuration separately and include Secure; ShipReady has a distinct check for the None-without-Secure combination.
Confirm the cookie's actual role
Review the named cookie in the deployed application before changing it. The scanner uses a name heuristic and does not determine whether the cookie carries authentication state.
How to verify the change
Inspect the deployed Set-Cookie response
Exercise the route that sets the cookie and inspect its final response headers without recording the cookie value. Then test the application flows that rely on the chosen policy in supported browsers.
Expected: The intended cookie has an explicit SameSite policy appropriate for its flow, and the tested application flow continues to work.