concept Frontend & browsers
HTTP cookies
An HTTP cookie is a small name/value state item delivered in `Set-Cookie` and potentially returned in later `Cookie` request headers.
What it means
An HTTP cookie is stored according to its attributes and may be attached to later eligible requests; JavaScript access is a separate question. Domain, Path, Secure, SameSite and HttpOnly affect different decisions. A stored cookie is not automatically sent on every request, nor is every sent cookie readable through document.cookie. Set-Cookie reference
Try it
Simulation — use a virtual cookie jar. Start with a host-only cookie for app.example.com; switch the request to www.example.com to see that the host-only cookie is not sent. Try a domain cookie, a Secure cookie over HTTP, an HttpOnly cookie and SameSite Lax in top-level versus subresource requests. A SameSite=None cookie without Secure is rejected in this explicit browser-like fixture. Reset clears the virtual jar and request context. Script visibility is evaluated for a separately opened first-party document at the selected request host, path and scheme; this is not a third-party-frame test.
Virtual cookie jar
Test storage, attachment to one HTTP request, and document.cookie visibility in a separately defined page context.
The cookie is stored in the invented jar. HTTP sending requires host, path, transport and SameSite eligibility. The script result is checked separately against the selected test document at https://app.example.com/account/dashboard: host, path, transport and HttpOnly apply, but the request's SameSite context is not reused as a script-access rule.
| Observation | Model value |
|---|---|
| Stored? | Yes |
| Host matches? | true |
| Path matches? | true |
| Scheme permitted? | true |
| Request SameSite permits? | true |
| Request Cookie header? | none |
| Script document | https://app.example.com/account/dashboard (first-party test document) |
| Script view | Not inspected |
Local, bounded educational fixture. No DNS, mail, certificate, network, socket or external request is performed.
About this model
An invented cookie is set by https://app.example.com; no browser storage, network or document.cookie is accessed. The script view represents a first-party test document at the chosen request host, path and scheme. The SameSite context control applies only to the HTTP request; script access is assessed separately. Real browsers have additional privacy/partitioning restrictions.
See the article’s protocol sources and model limits. The scene does not alter a real system.
How the mechanism works
Servers send a Set-Cookie header with attributes; user agents enforce storage restrictions and decide on later inclusion. A host-only cookie is scoped to its origin host rather than sibling subdomains. A permitted Domain attribute can broaden subdomain eligibility but must satisfy domain-matching rules. A cookie Path is a request-path filter, not a general confidentiality boundary. Secure restricts sending to secure contexts; HttpOnly prevents access through common document-cookie interfaces but does not stop eligible cookies from being sent with HTTP requests.
SameSite limits cross-site request inclusion based on the declared mode and navigation context. In this fixture, explicit Lax allows a cross-site top-level safe GET but not a cross-site subresource. Explicit None needs Secure under modern cookie rules. User agents may also block third-party cookies, partition state, enforce prefixes, expiration and size limits differently. The model does not silently assume identical browser defaults.
Why a stored cookie is not necessarily sent or script-readable
In this model an invented cookie is initially set over HTTPS on app.example.com. Give it the host-only scope and Path=/account:
| Later context | Sent in request? | Read by script in matching first-party document? |
|---|---|---|
HTTPS app.example.com/account/dashboard, HttpOnly off, same-site | Eligible | Eligible |
HTTPS www.example.com/account/dashboard | No: wrong host | No: wrong host |
HTTPS app.example.com/blog | No: wrong path | No: wrong path in this document |
HTTP app.example.com/account/dashboard, Secure on | No: insecure scheme | No: insecure document in this simplified model |
| Matching HTTPS document, HttpOnly on | May still be sent | No: HttpOnly |
The script-view row is a distinct synthetic first-party document at the host, path and scheme chosen above; it does not inspect an actual embedded third-party frame. SameSite controls request sending in the selected context, not an independent document.cookie access permission. Path is not a security boundary against malicious same-origin code.
SameSite and HttpOnly answer different questions
Consider a synthetic HTTPS page with a cookie stored for app.example.com, Path=/, Secure, SameSite=Strict and HttpOnly. An eligible same-site HTTP request may carry the cookie, while ordinary page JavaScript cannot read it through document.cookie because of HttpOnly. In a cross-site request context, SameSite can independently restrict whether it is sent. Neither attribute proves a cookie was actually sent: domain/path, user-agent policy, request context and storage conditions still matter.
Changing SameSite cannot make an HttpOnly cookie script-readable, and removing HttpOnly to debug a missing request would weaken a different security boundary. Compare the response that set the cookie with a specific later request and document context; do not paste session values into support logs. This is a local eligibility model, not an inspection of any real browser cookie store. Set-Cookie attributes
In practice
For a site you control, inspect Set-Cookie, the actual request URL/scheme/context, the outgoing Cookie header and the executing document context separately. Never paste live session cookies into a public inspector. Review Secure, HttpOnly and SameSite settings without assuming any one attribute prevents CSRF, XSS or all tracking; test sensitive flows in real target browsers.
Limits and common mistakes
The widget never accesses document.cookie, LocalStorage, third-party services or a live browser's cookie jar. It represents one invented cookie with explicit context choices; this is not a conformance test for any particular browser version, nor legal or regulatory privacy advice.
Key takeaways
Do not equate storage with request inclusion or script access. Explain each observed cookie decision using the actual request and document context, then verify browser-specific privacy behavior outside the teaching model.
Frequently asked questions
Editorial questions, answered from the sources listed for this article.
Does HttpOnly stop the browser from sending the cookie?
No. HttpOnly restricts access from document-level scripts; an otherwise eligible HTTP request may still include the cookie.
Can Cookie Path hide a session from all other same-origin scripts?
No. Path filtering affects cookie eligibility, but it is not a reliable same-origin security boundary. Treat session values as sensitive and rely on properly designed application security and HttpOnly where appropriate.
Can SameSite stop all cross-site requests?
No. It influences cookie inclusion under specified contexts; it is not a universal network-request or CSRF-protection switch.
Does Secure mean the cookie value is encrypted at rest?
Not by itself. Secure constrains eligible network transfer contexts; endpoint storage and device protection are separate concerns.
Sources & model boundaries
Primary references used for this explanation. The interactive example is an educational model, not a live check.