Despite developed front end programs with the witness of 30k+ lines of code and several projects, big or small, mastering React framework and its pals (like Zustand, vite, etc.) when I was asked about some basic concepts, I felt so dumbed that lead me here to take some notes.
Cookie, what a corny term. As I can remember, I have been working with front end techs without Cookies for a long time, which is almost cleared from my memory. Technically, it is a storage with a very little capacity (4 kB) can be manipulated from both front end and back end, except for those with HTTP only attribute.
I was asked about the fields of Cookie and I fail to put forth an answer. Here’s the answer:
- Core Fields: Name=Vlue, Expires, Max-Age, Domain, Path, Secure & HttpOnly,
- Expanded Fields: SameSite, Partioned, Priority, SameParty.
I will emphasize core fields in details as it matters the security and being of a cookie.
Name=Value is where you actually store your data. It is a key-value pair but in a heterogeneous form rather than a colon-seperated dictionary. It connects the name and value with a “=”. And definition goes like
userID = testuser.
Expires and Max-Age defines the lifespan of a cookie record. Expires field should be formatted in HTTP date time pattern while the field Max-Age should be given seconds value. If Expires is not designated, this record will be regarded as a session cookie and expire when the browser quits. And be noted, Max-Age has a higher priority than Expires.
Domain restricts the effectiveness of a cookie in terms of domain name. Developer may set Domain = .example.com and the cookie will take effects in .example.com. Modern browsers are capable of dealing with dot in the beginning of a domain name i.e. developer is allowed to ignore the dot while it is a must in earlier standard.
Path, assuming the similar role comparing with Domain, regulates the effectiveness of a cookie as well. But it happens in a path level, like path=/api.
Secure is simple, when it is true, the cookie is only available in HTTPs connections.
HttpOnly is somewhat ingenious. As mentioned, cookies can be accessed from both front end and backed end in most time. In the front end, developers most likely to access cookies with JavaScripts in the following way,
const cookies = document.cookieAnd when HttpOnly is true, this way is a no way. HttpOnly prohibits developers from accessing cookies by front end scripts in light of security reasons. A useful practice for developers is carrying access token in a HttpOnly and Secure cookie which avoids XSS attacks by improper or illegal injected scripts exploiting those sensitive security information.
Back to where we began. Why did I pass on Cookies for over 30k+ lines of code projects? Because of more modern and convenient alternatives: localStorage, sessionStorage, and IndexDB. These databases provide larger capacity and easier access method. And it can be widely supported by modern front end frameworks like persistent Zustand store in localStorage. I love it. But I have to admit that it is risky to keep access token in localStorage rather than an HttpOnly, SameSite, and Secure cookie.
Leave a Reply