Answers · The network and the web

Where should a session ID be stored so JavaScript can't read it?

In shortStore it in an HttpOnly cookie set by the server; that is the only browser storage JavaScript running on the page cannot read.

Store it in an HttpOnly cookie set by the server. That is the only browser storage JavaScript running on the page cannot read, and it is also the storage the browser will attach to requests for you.

What the browser will and will not expose

localStorage is a JavaScript API. If a script is running in your origin, it can call localStorage.getItem('sid') and get the string; the same is true for sessionStorage, a variable in a page script, or a cookie without HttpOnly. The browser has no way to tell your code from an injected dependency, a compromised third-party script, or an extension with page access. HttpOnly is a flag the server sets on the cookie, and the browser then omits that cookie from document.cookie while still sending it on requests. The page cannot read it because the browser refuses, not because your code chooses not to look.

FIG 1

Where it is kept	Readable by script on the page	Attached by the browser
HttpOnly cookie	no	yes
localStorage	yes	no
page variable	yes	no
ordinary cookie	yes	yes

The automatic sending is not a flaw to be avoided. It is the mechanism. When the browser makes a same-origin request it attaches the cookie according to Path, Domain and SameSite, and the server reads it from the Cookie header. A value in localStorage is never attached by the browser; your JavaScript must read it and put it into a header or a body. That means the value has already passed through code on the page, which is exactly the code you are trying to keep it away from.

p = \frac{n}{s}

Take a service with $10^7$ live sessions and 128-bit identifiers. The identifier space is $2^{128}$ , about $3.4\times10^{38}$ . A single random guess hits some live session with probability $10^7/(3.4\times10^{38})=2.9\times10^{-32}$ . At $10^6$ guesses per second, a year gives $10^6\times365\times24\times60\times60=3.15\times10^{13}$ guesses, and the chance of at least one hit is about $3.15\times10^{13}\times2.9\times10^{-32}=9\times10^{-19}$ . That is why the identifier can be treated as a password and why its storage matters: the guess is not the weak part.

FIG 2The header that puts it out of reach

plaintext

Set-Cookie: sid=K7nQv2Xp...; HttpOnly; Secure; SameSite=Lax;
Path=/; Domain omitted; Max-Age=1209600

HttpOnly        page scripts cannot read it
Secure          never sent over an unencrypted connection
SameSite=Lax    not attached to most requests started by another site
Path=/          sent to the whole application
Domain omitted  stays on the exact host, not every subdomain
Max-Age         how long the browser keeps it, in seconds

The first five attributes are protections; Max-Age is a lifetime. Omitting Domain keeps the cookie on the exact host, not every subdomain.

The natural guess, and why it fails

The natural guess is that localStorage is safer because the browser does not send it automatically. That is true and irrelevant. Automatic sending is only dangerous if another site can cause your browser to send the cookie without your page's consent, which SameSite limits. Code already running on your page does not need automatic sending: it can read localStorage directly and send the value wherever it likes. Moving the value into localStorage does not take it out of JavaScript's reach; it puts it in JavaScript's own storage. If an injected script can run, it can read the session and use it. The HttpOnly cookie is the one value that script cannot read, even though it can still cause requests to be made with it.

Two limits are worth stating. HttpOnly protects confidentiality from page code, not integrity: a script that cannot read the cookie can still make requests from the page, and the browser will attach the cookie, so an injection can act as the user for the session's lifetime. SameSite=Lax reduces cross-site requests, and Secure keeps the cookie off unencrypted connections, but neither makes XSS harmless. If your JavaScript genuinely must read the identifier, an HttpOnly cookie is impossible; then the identifier is not secret from page code, and you should treat it as a bearer token with a short life and narrow scope rather than pretend it is protected.

The header should be explicit. HttpOnly, Secure, SameSite=Lax, Path=/, no Domain, and a Max-Age you chose. Max-Age=1209600 is 14 days, since 14×24×60×60=1,209,600. For a session identifier that is long; the number should follow what the session can do, not what is convenient. Issue a fresh identifier at sign-in and discard the old one, so a value planted in the browser beforehand cannot become the session.

Worth keeping

An HttpOnly cookie is the only browser storage that page scripts cannot read, because the browser enforces the restriction rather than your code.
The fact that localStorage is not sent automatically is not protection: any script running on the page can read it and send it.
HttpOnly protects the value from being read by injected code, but it does not stop that code from making requests that use the cookie.

Where this goes next

This question is one step of Proving Who You Are, a course that works through its subject from the beginning. The page that teaches this part of it is Not Asking Again Every Time, and it reads the whole way through whether or not you have an account.

What an account changes is the practice: problems standing under every idea, marked with a reason rather than a tick, in a copy of the course that is yours.

Read that page The whole course

Where should a session ID be stored so JavaScript can't read it?

What the browser will and will not expose

The natural guess, and why it fails

Worth keeping

Where this goes next

Read alongside