HTTP Cookie
An HTTP cookie is a small name-and-value item set by a server or script. The browser sends it back only when rules for site, path, lifetime, and security allow it.
Another example
A session ID cookie uses Secure, HttpOnly, SameSite=Lax, Path=/, and an expiry. The browser sends it only in matching cases and page scripts cannot read it. The cookie is not the signed-in session itself, and HttpOnly cannot stop every cross-site request.
Main parts
- 01name-value pair
- 02scope attributes
- 03lifetime and security flags
Use it when
Use this term when a browser must keep a small piece of HTTP state with clear scope rules.
Do not use it when
Do not put secrets, large data, or unchecked app objects in cookies. No single cookie setting gives full protection.
Name used in code
Set-Cookie: name=value; Secure; HttpOnly; SameSite=Lax 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 HTTP Cookie for this system while keeping data correct, secure, and easy to operate. User context: A session ID cookie uses Secure, HttpOnly, SameSite=Lax, Path=/, and an expiry. The browser sends it only in matching cases and page scripts cannot read it. The cookie is not the signed-in session itself, and HttpOnly cannot stop every cross-site request. Technical concept or control: HTTP Cookie. Why it fits: Use this term when a browser must keep a small piece of HTTP state with clear scope rules. Do not use it when: Do not put secrets, large data, or unchecked app objects in cookies. No single cookie setting gives full protection. 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): The standard covers only the listed scope. It does not choose the visual style, product decision, or Vibulary example. 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 HTTP Cookie. Definition: An HTTP cookie is a small name-and-value item set by a server or script. The browser sends it back only when rules for site, path, lifetime, and security allow it. 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.