Browser cookies are small pieces of information that are stored on the user’s computer while they browse websites. They are used to help to track user activity and preferences while browsing. They are not computer programs and don’t contain any executable code, only small bits of information.
What happens when you accept cookies from a website?
Accepting cookies means that you permit a website to store settings, preferences and other bits of information on your computer. Most websites work just fine without cookies, but advanced features like saving preferences or even logging in as a user will not work, because it becomes impossible for the website to keep track of your browsing session.
Session vs. persistent cookies
Cookies can have an expiry date, until what time they’re allowed to exist on the user’s computer. Cookies without a date of expiry only live for as long as the browser is open and they’re not saved onto the disk. To remove session cookies, simply restart the browser – this is why a lot of sensitive websites ask you to close your browser after logging in – it clears all the session information that may still exist in the system.
To remove persistent cookies, open Privacy and Security / Clear browsing data or open Privacy and Security / Cookies and other site data / See all cookies and site data to review them.
Session cookies are often used to track user activity locally, for example, to remember if a user is logged in.
First-party cookies
First-party cookies are the ones set by the very website you’re browsing. Only the website itself can access it and it’s not possible to track cross-site behavior using them. All browsers support first party cookies and they’re an essential part of the working web ecosystem.
Third-party cookies
These are the evil ones, that allow easy cross-site tracking and various privacy-invading features. They are not set by the website you’re browsing but a third party that hosts for example an embedded image that’s loaded from the website. Fewer and fewer browsers support third party cookies, for example, Google Chrome is expected to stop supporting them completely in 2022.
Cookie consent
You have all seen those dreadful cookie consent walls that are poisoning the whole web recently, thanks to GDPR. The reason is that because cookies store information on the users computer and allow easy tracking, more and more jurisdictions now require explicit consent from the user to comply with regulations like CCPA, GDPR and EU Cookie Law. The whole legal landscape is still changing and some of it is a grey area, so everyone’s trying to play safe and get consent from the visitor. Why GDPR explicitly bans getting consent and selecting YES by default, sites often use dark patterns (user interface elements that make it very easy to click OK and difficult to DENY) to force users into acceptance.
Processing cookies with JavaScript
To set a cookie from a webpage, it’s simply a matter of of running a one liner javascript or a similar server side command. This example sets a session cookie named “username” with the value “techtipbits”.
document.cookie="username=techtipbits"This way it’s instantly set as a session cookie and exists as long as the browser session exists. Appending a date to it makes it a persistent cookie that is saved to the disk and exists for as long as the date permits:
document.cookie = "username=techtipbits; expires=Mon, 10 May 2021 13:19:00 UTC";Removing cookies is done by setting a cookie with the same name and expiry in the past. This will automatically remove them from the cookie storage.
Cookies can also have a set scope that limits their availability to a specific path or domain – you can read more about specific cookie parameters here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie
Multiple cookies can be set at the same time by repeating the same command – the browser will keep appending them to document.cookie.
Reading and processing cookies is done by using the document.cookie variable but it’s not straightforward because the same it’s not stored as an array but a simple string containing all the available cookies.
Every time a new one is created it’s appended to the “document.cookie” string. Parsing this can be painful in JavaScript because it’s not a matter of simply reading the string as an array – you can either write your own or use an already existing library, for example, https://github.com/js-cookie/js-cookie.
Server side cookie processing
After a cookie is set, any page or resource that’s loaded by the browser is sent this cookie. This is technically done by the browser sending a “Cookie: thisis=acookie” header together with the request, for example to load a page from our website with a cookie set, the request would look like this:
GET / HTTP/1.1
Host: techtipbits.com
Cookie: name1=value1; name2=value2
Accept: */*The server can also ask the browser to set cookies by sending the “Set-Cookie” header back in the response. This will result in that subsequent requests will include that cookie.
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: name3=value3
[here comes the real content from the request]Session hijacking
Cookie storage is sensitive information and anyone getting hold of this data can impersonate web requests on your behalf. Technically this means that, for example, any request to a website that you’re logged in that contains your session cookie will be identified as coming from you as long as you’re logged in. This is called session hijacking and it can defeat complicated authentication schemes (even 2FA / MFA that you can read more about here: Protect your online accounts with multi-factor authentication) because the session ID is generated AFTER 2FA is entered.
This is one of the reasons why it’s a good idea to use a separate browser (or even a separate computer) for sensitive operations, like logging in to your bank’s website and log out as soon as you’re done. This ensures that these cookies are invalidated quickly and no third party can copy them and impersonate browser requests.
