Secure Cookie Attributes
Secure cookie attributes control how a cookie travels and whether scripts can read it. They also control cross-site use, which host and path receive it, and how long it lasts.
Another example
A response sets `__Host-session` with `Secure; HttpOnly; SameSite=Lax; Path=/` and no `Domain`, then changes it after sign-in. A third-party payment return uses its own limited correlation cookie. It does not weaken every session cookie. Sign-out also ends the server session.
Main parts
- 01Name prefix and value
- 02Transport/script/site restrictions
- 03Scope and lifetime
Use it when
Give a cookie the smallest useful scope and life. Session cookies should normally use `Secure`, `HttpOnly`, a chosen `SameSite` mode, and a host prefix.
Do not use it when
`Path` is not a security wall. Do not set a wide `Domain` without need or put bearer secrets in script-readable cookies. Never use `SameSite=None` without `Secure`.
Name used in code
Set-Cookie: __Host-name=…; Secure; HttpOnly; SameSite=Lax/Strict; Path=/; Max-Age=… Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Secure Cookie Attributes for this system while keeping data correct, secure, and easy to operate. User context: A response sets `__Host-session` with `Secure; HttpOnly; SameSite=Lax; Path=/` and no `Domain`, then changes it after sign-in. A third-party payment return uses its own limited correlation cookie. It does not weaken every session cookie. Sign-out also ends the server session. Technical concept or control: Secure Cookie Attributes. Why it fits: Give a cookie the smallest useful scope and life. Session cookies should normally use `Secure`, `HttpOnly`, a chosen `SameSite` mode, and a host prefix. Do not use it when: `Path` is not a security wall. Do not set a wide `Domain` without need or put bearer secrets in script-readable cookies. Never use `SameSite=None` without `Secure`. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): A formal document may still be a draft, release candidate, or final version. Check its status and browser or platform support. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Secure Cookie Attributes. Definition: Secure cookie attributes control how a cookie travels and whether scripts can read it. They also control cross-site use, which host and path receive it, and how long it lasts. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.