HTTPS Persistence: Exploring Cookies, Sessions, and Tokens

HTTPS Protocol

HTTPS serves as the secure counterpart to HTTP, offering an extra layer of protection through SSL/TLS encryption. This cryptographic technique ensures that all data transmitted between the client and the server remains confidential and immune to eavesdropping and tampering.

Operating within the client-server model, HTTPS functions similarly to HTTP. Clients send requests to servers, and servers respond accordingly. However, both HTTP and HTTPS share a stateless nature. In other words, each request-response cycle stands alone, with servers not retaining any information about previous interactions. When a client sends a request, the server processes it, responds, and then forgets about the request. Subsequent requests from the same client are treated as entirely new, devoid of any prior context.


The development of cookies was a solution to a server’s tendency to forget prior communications with clients. These small pieces of data enable the storage of session information between the server and client, allowing for better interaction and customization.

How Cookies Work? When a client visits a website, a unique Cookie ID is sent to their browser, while the actual cookies are stored on the server’s database. Cookies serve various purposes, including session management, personalization, and tracking.

Session Cookies are essential for managing user sessions on a website. They help retain important information like login credentials and shopping cart contents, ensuring a seamless experience during the visit. As users navigate the site, session cookies provide the website with the memory it needs to remember the ongoing session. These cookies are specific to the server and not shared with other machines.

Personalization cookies enhance the user experience by storing individual preferences, such as language settings and currency choices. These small data files persist on the user’s browser, even after it is closed, ensuring that the website retains customized settings for future visits.

Tracking Cookies play a crucial role in recording and analyzing user behavior. When a user visits a website, their browser stores a unique tracking cookie. This cookie does not contain any information about the user’s tracking history itself. However, if the user visits other websites within the same ad network, those sites can search their database and match the user’s profile to their previous viewing history, enabling targeted advertising.

For the remainder of this article, we will be focusing on session cookies so here is a recap. Session cookies are established by the server when a user visits a website, as it sends a unique session ID to the client’s browser. The session ID serves as an identifier for the server to associate the session with the user’s information and activity which is stored in a database or file system. Once the user ends their session, either by closing the browser or being inactive for a specified period, the session cookie is deleted, and the server marks the session as concluded, clearing any related session data.


Tokens, also known as JWT (JSON Web Tokens), eliminate the need for a database lookup by containing all client information required for identification and verification within themselves. These self-contained tokens encrypt essential data and are sent with requests to the server, replacing the need for session ID cookies and streamlining the communication process.

A JWT consists of three parts: the header, the payload, and the signature. The header contains the token type (JWT) and the signing algorithm, and it is base64Url encoded.

The payload of a JWT is flexible, and developers can choose the specific data to include based on the application’s requirements. It typically carries information about the user and additional data relevant to the specific application like user ID, role, permissions, and expiration time.

The signature is created by applying a signing algorithm to the header, payload, and a secret key known only to the server, and it ensures the JWT’s integrity and authenticity.

When the client sends a request, the JWT is included, and the server can verify its authenticity by recalculating the signature with the provided secret key. This process ensures secure information transmission without additional database lookups. JWTs are particularly useful for APIs as each request contains client verification, reducing the need for the API server to track user sessions. Additionally, JWTs can be verified by any server, making them versatile and scalable for various applications.

JWT Flaws

Once a JWT is issued, it remains valid until it expires, even if it gets compromised or leaked, potentially creating a serious security vulnerability. Implementing a deny-list technique becomes necessary to handle revocations, resulting in a more complex setup to manage compromised tokens.

Once a JWT is issued, the information it carries remains static until the token expires. This means that if a user’s access levels or permissions change or if the user is removed from the system, the JWT will not automatically reflect these updates. Proper mechanisms must be implemented to handle token updates or incorporate real-time checks to ensure the token’s data aligns with the current state of the user to avoid potential access problems or security risks.

One of the disadvantages of using JSON Web Tokens (JWTs) is their potential for increased space usage compared to other authentication methods. The primary reason for this lies in JWTs’ self-contained nature, where they carry all the necessary information within the token itself. The larger payload size can impact network performance, especially when these tokens are transmitted with each request. This issue becomes more pronounced in cases where bandwidth and latency are critical concerns, such as mobile applications or scenarios with high traffic volumes.

Session Cookie Flaws

Session cookies are tied to a specific server, which becomes problematic when scaling the application across multiple servers. In a load-balanced environment, if a logged-in user is redirected to a new server, their existing session data is lost. To overcome this, sessions must be stored in a shared database or cache which adds complexity to the system.

Cookies are not the most suitable option for API authentication, especially when dealing with one-time resources for authenticated end-users. APIs don’t need to keep track of user sessions, and cookies, designed for session tracking, might not align with API authentication needs.

Session cookies can make both session hijacking and CSRF attacks possible due to the way they store and handle user session information. Since session cookies contain a unique session ID, an attacker who gains access to this ID can effectively hijack the user’s session and impersonate them on the website.

Session hijacking becomes a real threat when session IDs are not adequately protected, making them susceptible to interception through methods like packet sniffing or session replay.

Session cookies are automatically sent with each request to the server, including those initiated by malicious websites during a CSRF attack. When a user unknowingly visits a malicious site, the attacker can craft requests to the target website using the user’s session cookies, tricking the server into treating the unauthorized requests as legitimate ones. This allows the attacker to perform actions on behalf of the authenticated user without their consent.


HTTPS safeguards sensitive data through SSL/TLS encryption, providing users with confidence in their online interactions. Cookies play a vital role in session management, personalization, and tracking, enhancing user experiences while requiring careful consideration of potential vulnerabilities. On the other hand, JWTs offer a more streamlined and scalable approach to authentication, particularly for APIs, but their static nature and the need for proper token management must be acknowledged.