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
Ask three different questions about a cookie: was it accepted into storage, is it eligible for the present HTTP request, and can a script in a particular document see it? The answers can differ. Whether it is stored or sent depends on attributes and user-agent policy. Scope (Domain, host-only and Path), transport (Secure), script visibility (HttpOnly) and request context (SameSite) answer different questions. A cookie is not an HTTP cached page, and a cookie value is not automatically proof of a valid authenticated session.
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.
In practice
When debugging a login or personalization workflow, inspect developer tools in a controlled test account without transmitting session tokens to support staff. Compare response Set-Cookie, cookie storage outcome, request host/path/scheme and the presence of Cookie on a subsequent request. Test privacy settings and embedded contexts separately. Stop before weakening Secure/HttpOnly flags or widening Domain solely to make one request work; identify the intended session trust boundary and rollback any unsupported change.
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
Cookie storage, request inclusion and a specifically located document’s script access are separate decisions. Domain/Path and Secure scope matter to both request eligibility and the modeled script document; SameSite additionally influences the request context, while HttpOnly blocks document.cookie access. Inspect the explicit browser and request context; do not infer third-party behavior from the teaching jar.
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.
Sources & model boundaries
Primary references used for this explanation. The interactive example is an educational model, not a live check.