A session cookie's attributes decide where the browser stores and sends it, whether scripts can read it and how it behaves across site boundaries. A secure-looking header can still fail a login flow if the domain or path is wrong. Conversely, a working login can leave an unnecessarily broad cookie scope.
Review the cookie as a lifecycle: creation, browser acceptance, request attachment, renewal and deletion. Inspect the actual Set-Cookie response and subsequent requests. A server log showing that it emitted a header does not prove the browser accepted or returned the cookie.
Give each attribute a specific job
The cookie auditor parses pasted Set-Cookie lines and reviews attributes. It excludes cookie values from its report. It does not inspect a remote browser's cookie store or prove that a particular response was accepted under that browser's policies.
Secure restricts transmission to secure contexts according to cookie rules. HttpOnly prevents access through ordinary script cookie interfaces. SameSite controls attachment in cross-site contexts. Domain and Path govern scope. None of these attributes replaces server-side session validation or expiry.
Start with the narrowest scope that supports the application. A session used only by app.example generally does not need to be shared with every sibling subdomain. Reducing scope helps keep a less-trusted sibling from becoming part of the session's operational boundary.
Set-Cookie: __Host-session=EXAMPLE_VALUE;
Secure; HttpOnly; Path=/; SameSite=LaxThis illustrative cookie uses a host prefix and omits Domain. Use a real unpredictable session value generated by the server, and set expiry according to the application's session design. Do not deploy the example value or assume this SameSite choice fits every integration.
| Attribute | Purpose | Limit |
|---|---|---|
| Secure | Restricts sending over insecure transport | Does not stop all application attacks |
| HttpOnly | Limits script access to the cookie value | Scripts can still trigger authenticated requests |
| SameSite | Controls cross-site attachment | Does not replace a complete CSRF design |
| Domain | Expands matching host scope when allowed | Can include sibling subdomains unintentionally |
| Path | Limits request-path matching | Is not a strong security boundary between applications |
| Max-Age or Expires | Controls browser retention | Server-side revocation remains necessary |
Distinguish site from origin
SameSite uses a site concept that differs from origin. Origin includes scheme, host and port, while site relationships depend on the scheme and registrable-domain rules used by browsers. Two subdomains can be same-site while still being different origins for JavaScript and CORS.
This matters when a sibling application is less trusted. SameSite alone should not be treated as protection against every request originating from a related subdomain. Review the full trust boundary, CSRF controls and which applications can influence the user's browser.
Use browser evidence when a login integration behaves unexpectedly. Record the top-level site, frame origin, request method and navigation type. Describing a request merely as external can hide the distinction that determines cookie attachment.
Choose SameSite for the real flow
Strict applies a restrictive cross-site attachment policy and can affect entry into an authenticated site from an external link. Lax permits certain top-level navigation cases while restricting other cross-site uses. None permits cross-site attachment subject to Secure and other browser policies.
A payment return or federated login can involve redirects and methods that differ from an ordinary link click. Test the provider's real flow, including cancellation and error paths. Do not choose None everywhere merely because one integration failed; identify which cookie and request actually need cross-site use.
Browser defaults and compatibility details can vary. Set the intended attribute explicitly and verify it on supported browsers. A policy parser can explain the configured value, but only a browser test shows whether the particular flow sends the cookie.
Use prefixes with their acceptance rules
The __Secure- prefix requires the associated secure-setting conditions. The __Host- prefix adds restrictions including Secure, Path=/ and no Domain attribute, binding the cookie more tightly to the host. Prefix spelling is part of the cookie name and its browser-enforced contract where supported.
A prefix does not make a predictable session identifier safe. The server still needs suitable randomness, rotation, validation and revocation. Prefixes constrain how the browser accepts the cookie; they do not authenticate the application's session database.
Test acceptance after adding a prefix. A server that keeps its old Domain attribute while renaming the cookie to __Host-session can cause the browser to reject it. Inspect the browser's blocked-cookie explanation rather than assuming the new name alone completed the change.
Diagnose a session lost after a payment return
Suppose checkout works until the payment provider returns the user to the application, where the session appears missing. Capture the return navigation's method, site context and Cookie header using a test account. Compare it with an ordinary same-site navigation that works.
If SameSite attachment rules explain the difference, redesign the return flow or use the appropriate narrowly scoped cookie strategy supported by the integration. Maintain CSRF and state validation. A missing cookie should not lead the server to trust unverified query parameters as proof that the payment belongs to the user.
Also check Domain, Path and expiry. The return may land on a different subdomain or path from the one that set the cookie. A redirect can conceal that change in a quick manual test. Follow the entire chain and identify the first request where the expected cookie is absent.
After fixing it, test successful payment, cancellation, repeated return URLs and an expired session. These cases confirm that the application recovers safely instead of merely making one happy path appear logged in.
Coordinate browser retention and server session state
Max-Age and Expires affect how long the browser retains a cookie, with defined precedence when both are present. The server must still enforce its own idle and absolute session limits. A client-supplied cookie should not remain valid simply because the browser continues sending it.
Rotate session identifiers at appropriate authentication and privilege boundaries. On logout, revoke the server-side session and expire the browser cookie using matching scope. Deleting a cookie with the wrong Domain or Path can leave the original stored cookie intact.
Session cookies without a persistent expiry can interact with browser session-restore behaviour. Do not rely on closing a window as the only security boundary for a sensitive session. Enforce time and revocation rules on the server and explain the product's sign-out behaviour clearly.
Account for browser restrictions beyond attributes
Cross-site cookies can be restricted by browser privacy policy even when SameSite=None and Secure are present. Embedded applications may need a different architecture or supported storage-access flow. A syntactically valid cookie is not a promise of third-party storage availability.
Partitioned cookies introduce an additional storage boundary in supporting browsers. Review their specific rules and the intended top-level context before using them. Do not assume they recreate unrestricted cross-site identity sharing; their purpose and behaviour differ.
Keep diagnostic reports free of live cookie values. A session identifier can grant access, and a copied header can end up in tickets or logs. Share attribute structure and redacted request evidence unless an authorised secure process specifically needs more.
Check for duplicate names with different scopes
Browsers can store cookies sharing a name but having different Domain or Path scope. A request may then contain more than one value with that name, and server parsing can become confusing. During a migration, inspect the complete cookie store and expire obsolete scoped variants deliberately. Do not assume that setting a new host-only cookie removed an older domain cookie. Verify which value the server actually uses before declaring the session change complete.
Frequently asked questions
Does HttpOnly prevent every effect of an injected script?
No. It limits direct script reading of the cookie value, but injected code may still perform actions in the authenticated page. Prevent injection and enforce server-side authorisation. HttpOnly is valuable, but it does not make an otherwise vulnerable application safe.
Does Path isolate two applications securely?
Path controls cookie attachment matching and should not be treated as a strong isolation boundary. Applications sharing a host can interact through other browser behaviours. Use appropriate origin and hosting separation when applications require independent trust boundaries.
Why is my __Host- cookie rejected?
Check Secure, Path=/, absence of Domain and the secure setting context. Inspect the browser's rejection reason. A prefix creates acceptance requirements; renaming an existing broadly scoped cookie without updating its attributes can break storage.
Should I use SameSite=None for all sessions?
Choose it only when the actual flow requires the corresponding cross-site behaviour and the rest of the security design supports it. Test alternatives and keep CSRF protection. A broad setting can increase exposure without fixing a domain, path or expiry mistake.
Why did logout leave the cookie visible?
The deletion response may not match the stored cookie's scope, or another response may set it again. Inspect name, Domain and Path, then verify server-side revocation independently. A visible stale cookie should not continue authorising a revoked session.
Can the auditor inspect cookies on another website?
It reviews pasted Set-Cookie text; it does not read another origin's browser storage. Use authorised developer tools on the affected site to inspect acceptance and request attachment. Remove values before sharing the configuration for review.
What confirms a cookie change is correct?
Verify browser acceptance, expected attachment across real flows, absence where it should not be sent, and effective logout and expiry. Include supported browsers and embedded contexts. A clean parser result is a useful configuration check, not the complete session test.