Questions and answers

An HTTP cookie is a small named value that a server asks the browser to store with the Set-Cookie response header. The browser sends it back in the Cookie request header on later requests that match its rules, which lets a stateless protocol remember a login, a basket or a preference. The request header carries only the name and value, never the attributes. RFC 6265 is the specification that defines this mechanism, and MDN's guide to HTTP cookies is a good plain-language companion.

Link to this question

A cookie is sent to the server automatically with matching requests, while localStorage never leaves the browser unless your own code sends its contents. Cookies can carry flags such as HttpOnly and Secure, so scripts cannot read an HttpOnly cookie. LocalStorage is readable by any script on the page, which makes it a weaker home for session tokens. MDN notes that modern storage APIs are recommended for general client-side storage because cookies are sent with every request and can hurt performance.

Link to this question

RFC 6265 says browsers should support at least 4096 bytes per cookie, counting name, value and attributes, at least 50 cookies per domain and at least 3000 in total. These are minimums that servers should plan around, and real limits vary by browser, so test the browsers you support. MDN describes about 4 KB per cookie as the usual maximum. Keep cookies small, because they travel with every matching request, and store bulky data on the server.

Link to this question

Send a Set-Cookie header with the same name, domain and path as the original, and an expiry in the past or a Max-Age of zero or less. MDN describes this as the way to remove a cookie immediately. If any of the three identifying parts differ, the browser treats it as a different cookie and the original stays. This mismatch is the most common reason a logout appears to work while the user remains logged in.

Link to this question

A session cookie is a cookie with no Expires or Max-Age attribute, so the browser treats it as temporary and normally removes it when the session ends. The browser decides when that is, and MDN warns that session restore can keep session cookies alive indefinitely. A session cookie is not the same as a server-side session; it usually just carries an identifier. For login state, prefer a short lifetime plus server-side idle and absolute timeouts.

Link to this question

The usual causes are a different host, a path that does not match, a Secure cookie on a plain HTTP request, an expired lifetime, a SameSite restriction or a blocked third-party context. Work through them in that order using the browser's developer tools: the network panel shows Set-Cookie on responses and, for each request, which cookies were sent or filtered out, often with a reason. A cross-origin fetch also omits cookies unless credentials are enabled.

Link to this question

HttpOnly hides a cookie from page scripts, so document.cookie cannot read it, while the browser still sends it with requests. MDN notes it is still included on fetch and XMLHttpRequest calls. This limits cookie theft through cross-site scripting, because injected script cannot copy a session identifier. It does not stop injected script from acting as the user through requests that carry the cookie, so it reduces damage rather than preventing XSS. Preventing injection remains the real fix.

Link to this question

The Secure flag tells the browser to send the cookie only over encrypted connections, which means HTTPS. MDN notes that localhost is an exception for development. Current browsers also generally refuse to let an insecure response set or overwrite a Secure cookie, which blocks a trick where a network attacker plants a cookie. It only protects you if the whole site uses HTTPS, so pair it with redirects from HTTP and, where appropriate, Strict-Transport-Security.

Link to this question

It depends on the browser. MDN says some browsers use Lax as the default when SameSite is missing, and that this default is a more permissive Lax which also sends the cookie on cross-site POST requests within two minutes of it being set. Because the behaviour has had exceptions and may change, set the value explicitly on every cookie: Lax for ordinary session cookies, Strict for high-risk areas, None with Secure only for real cross-site needs.

Link to this question

Because MDN states that when SameSite=None is used, the Secure attribute must also be set, and current browsers reject a SameSite=None cookie without it. A cookie that travels across sites should at least be protected from plain HTTP interception. A correct header is Set-Cookie: widget=xyz; Secure; SameSite=None; Path=/. Even then, browsers that block or partition third-party cookies may still withhold the cookie.

Link to this question

__Host- is a cookie name prefix that makes supporting browsers accept the cookie only if it has the Secure attribute, was set from a secure page, has Path=/ and carries no Domain attribute. MDN states this guarantees the cookie is sent only to the host that set it. The result is a cookie locked to one host that sibling subdomains cannot overwrite. It is a strong default for login sessions that do not need to be shared across subdomains.

Link to this question

Many current browsers block or partition them by default, but behaviour differs by browser, version, private mode and user settings, so there is no single answer. Partitioning keeps a separate cookie jar per top-level site, so an embed cannot recognise a person across sites. Test embedded features in several browsers with default settings and again with stricter tracking prevention, and design them so that a missing cookie degrades gracefully instead of failing silently.

Link to this question

A Partitioned cookie is stored separately for each top-level site on which an embed appears, as part of CHIPS, Cookies Having Independent Partitioned State. MDN describes it as double-keyed by the setting origin and the top-level page, and says the Secure attribute must be set. A chat widget can then remember a conversation on each host site without being able to recognise the same person across different sites. Browser support has rolled out gradually, so check it before relying on it.

Link to this question

Yes. Many applications place a signed token in an HttpOnly, Secure cookie so that page scripts cannot read it. Because browsers attach cookies automatically, you then need CSRF protections such as a suitable SameSite value and anti-forgery tokens. Remember that a signature proves integrity, not secrecy, so do not put sensitive data in the claims, and plan how to revoke tokens, since a signed token stays valid until it expires.

Link to this question

Browsers attach cookies automatically, so a malicious page can trigger a request that carries the victim's session cookie, which is the heart of CSRF. MDN lists three main defences: CSRF tokens embedded in the page, checking Fetch metadata headers such as Sec-Fetch-Site, and requiring requests that are not simple. The SameSite attribute then adds defence in depth. Never change state on GET requests, because Lax still lets top-level GET navigations carry the cookie.

Link to this question

Injected script can read every cookie that is not HttpOnly and send it to an attacker, so session cookies should be marked HttpOnly. Even then, the script can make authenticated requests, because the browser still attaches the cookie. HttpOnly therefore limits theft but does not stop the attack. MDN defines XSS as getting a site to run malicious code as though it were its own, and the real fix is preventing injection through output encoding and a content security policy.

Link to this question

By default, MDN explains, credentials such as cookies are only included in same-origin fetch requests. For a cross-origin call you must opt in with the credentials option set to include, and the server must reply with Access-Control-Allow-Credentials: true and a specific origin in Access-Control-Allow-Origin, because a wildcard is not accepted with credentials. If either side is missing, the browser leaves out the cookie or ignores the response's Set-Cookie.

Link to this question

That is a legal question, and the answer depends on where you and your users are and on what your cookies do, so this site cannot give it. In general terms, privacy rules often treat cookies that are strictly necessary for a requested service differently from analytics or advertising cookies. Start by keeping an inventory of every cookie, including those set by embedded services, then read official sources and consult qualified counsel for your situation.

Link to this question

This site gives only general information and cannot say how the Digital Personal Data Protection Act, 2023 applies to your case, including whether and how it covers cookie-based identifiers. The Act governs digital personal data and centres on notice and consent, with rules issued in stages. Read the Act and its current rules on official government sites, rather than summaries, and ask qualified counsel how they apply to your service.

Link to this question

Open the browser's developer tools and use the Application panel, called Storage in some browsers, to list the cookies for a site with their name, value, domain, path, expiry, size and flags such as HttpOnly, Secure and SameSite. The Network panel shows the Set-Cookie headers on responses and the cookies sent with each request. Panel names vary slightly between browsers.

Link to this question