Browser cookies: sessions, expiry and security attributes

Useful to know

A browser cookie is a small value that the browser stores and sends in appropriate follow-up requests. Thus, the site can recognize, for example, a particular session or a remembered choice. This does not mean that all account information is found in the cookie. Often it contains only an identifier by which the server finds the remaining data. The difference is important: a small string in the browser can have great importance for access without itself resembling a password. [1]

The server sets the cookie using the Set-Cookie. header Later, the browser returns it via Cookie, if the request meets the applicable conditions. Term may be indicated by Max-Age or Expires. Without such a deadline, the cookie is usually a session, but a browser session recovery can also restore it. Therefore, "will necessarily disappear when closing the window" is not a reliable enough assumption when designing the exit from a user profile. [1, 2]

The Secure attribute limits sending to a secure connection, with features for local development. HttpOnly does not allow the cookie to be read through JavaScript interface document.cookie. These are different defenses. One refers to the transfer, and the other to access from a script. HttpOnly does not prohibit the browser from sending the cookie upon an appropriate request made through JavaScript. Therefore, the attribute reduces a specific risk, but does not make a vulnerable page safe with only one name in the configuration. [2]

SameSite manages sending in contexts of requests between sites. Strict, Lax and None values have different behavior ; None also requires Secure. The appropriate choice depends on the actual flow, for example, opening a connection, a built-in service, or an external login process. When changing, it is important to check these scenarios. The strictest possible value is not automatically correct for any application if it interrupts a necessary and properly protected user process. [2]

In terms of scripts, document.cookie has more features. Reading returns the available cookies as a string, and the assignment usually sets a separate cookie instead of replacing the entire list. Access is synchronous and there may be a cost to performance. There is also an asynchronous Cookie Store API for the appropriate environments. This is the reason why the code does not read the cookies unnecessarily in any frequently performed operation. A convenient interface does not mean that access to the stored state is free. [3]

A useful example is the "remember selected language" function. It has a different sensitivity and a different term than the administrative login cookie. If the two get the same settings by habit, an important difference between preference and authentication can be lost. When reviewing the system, it is good for each cookie to have a clear answer as to what it means, who should read it, and when it should stop acting. Thus, the settings follow the purpose of the data, instead of being a random combination of attributes.