Everything You Ever Wanted to Know About Session Management in Node.js (2023)

Session Management is a pretty scary term for a lot of developers. Most of the mechanics of session management are abstracted away from developers, to the point where they don’t properly learn about it until it’s necessary. Usually, this means a late night trying to figure out a vulnerability, a bug, or how to work with a new session management library. Hopefully, I can remove some of the magic behind session management in NodeJs and give you a good fundamental place to start. In this article, you will learn what sessions are, how to manage them in Node.js, and some details that should help you minimize bugs and vulnerabilities.

Overview of Sessions

I will start at the beginning. When a user uses your web application, they make an HTTP request to the webserver. The server then knows what to do with this request and returns a response. The user’s request must contain all the necessary information for the server to make a decision. For example, is the user authenticated? Is he/she authorized to view a specific page? Does the user have a shopping cart that needs to be displayed? All this information that makes the user experience feel seamless, as though he/she is using one continuous application, must be transmitted from the client to the server. If the application were to transmit all this data back and forth on each request, you would introduce massive security and performance concerns. There are many ways to streamline this effort, but for the sake of this article, I will focus on cookie-based sessions.

When a user sends a request to your web application, they will add a session cookie to the request headers. If this is the first time a user has requested your site, the server will create a new session cookie and return it to the client. The session is given an ID that both the client and server can reference. This enables the application to split the session data between that which is stored on the client-side and that which is stored on the server. For example, the cookie may tell the application the session ID and that the user is authenticated. The server can use this information to access the user’s shopping cart in the server’s store.

Of course, any time an application sends information to the client it could possibly end up in an enemy’s hands. The majority of your users aren’t necessarily bad actors, but bad actors are certainly looking for ways to exploit your application. Most security concerns should be addressed by you, the developer and maintainer of the application and the developer of whatever session management library you’re using.

Session Management Risks

As an aside, I should note that it’s generally better to use a well-established session management library than to roll your own. You will see a few examples of that later in this article. For now, let’s take a look at some common session security concerns.

Session Prediction

Each session has an associated session ID with it. It is very important that this session ID is properly randomized, such that an attacker cannot simply guess a few options and bypass any security associated with the session ID. Suppose your session IDs were sequential integers. An attacker could log in, create a new session, and see their session ID is 12345. The attacker could then try to pass the session ID 12344 or 12343 to the server in an attempt to hijack a session from another user.

Session Sniffing

In session sniffing, an attacker can use a sniffing application such as Wireshark or a proxy to capture network traffic between a client and server. As you’ve learned, that traffic will ultimately contain a request with a session cookie in it. This cookie will have the session ID which can then be hijacked.

Man-in-the-Middle Attacks

In a man-in-the-middle attack, an attacker sits between the web server and the client. The attacker can then pass requests from the client to the server and respond without detection from either. But along the way, the attacker has gained access to the session.

(Video) Session Management in NodeJS

Client Side Attacks

There are many strategies for attacking the client. Some of the best known are Cross-Site Scripting, Trojans, and malicious javascript codes. Sometimes it just takes some good old-fashioned social engineering to obtain session information from a client. The idea here is that the attack will attempt to exploit the client itself to get access from the cookie in the browser’s storage. For example, an attacker that can inject malicious Javascript code could inject the following javascript:

With that simple line of code, the attack can now gain access to the cookie along with all the session goodies in it.

Good Session Management Practices

All of this is probably a little scary, But many people are working on the other side to help prevent these attacks or minimize their impacts. Most of these strategies are rolled into session management libraries, and any library that is continuously maintained should be up to date with the latest security enhancements. But, it’s important for you, as a developer who takes security seriously, to understand what security should be in place.

Session Secret

Any good session management library should come with an option to change the session secret. It may have slightly different names but the idea is always the same. The secret is used to compute a hash against the session ID. This helps to prevent session hijacking by ensuring the session cookie hasn’t been tampered with.

Session Expiration

Another good practice is to expire the session after some predetermined time. There are two ways to expire a session: (1) based on inactivity or (2) absolutely. When you base your expiration on inactivity, it will keep the session open until the user hasn’t made a request for some amount of time. When you choose to expire it absolutely, then the session will expire after some predetermined time, regardless of activity. The session will then need to be refreshed. You should at least set an inactivity session expiration so you don’t have stale and vulnerable sessions available for attack.

Cookie Expiration

Similar to session expiration, you can also expire the cookie that was sent to the browser. Many times, cookies are set to expire when the session expires. However, it is possible to allow the cookie to remain available indefinitely. This is a poor decision for the same reason as session expiration. Generally, session expiration is a strong tool for minimizing the impacts of attack, but implementing cookie expiration is also helpful.

(Video) Understanding Authentication in Node.js - Sessions and Cookies - Web Development Concepts Explained

Regeneration of Session After Login

When a user first accesses your site, he/she can use an anonymous session. This is a fairly common practice where you want to track a user’s movements in your application but don’t want to require them to log in. For example, consider a shopping site where an anonymous user can have a shopping cart but can’t check out until he/she logs in. In this case, there is still a session ID provided to the user. When the user does log in, you should regenerate the session ID to prevent session fixation attacks against your web application.

Session Management in Node.js

Node.js has become wildly popular over the last 10 years. With it, several frameworks and session management libraries have cropped up to support it. Most frameworks use their own session management middleware. For example, express, the most popular server framework for Node.js, has the accompanying express-session for session management. Similarly, koa uses koajs/session for its session management.

For this article, I want to focus on express-session, as it is one of the most mature and widely used session management libraries available for Node.js. For a full rundown of the express-session package, you can view the readme here. Below are some of the highlights:

Registering the middleware for express-session is very simple.

var session = require('express-session')var app = express()app.use( session({ secret: 'SomeSuperLongHardToGuessSecretString', resave: true, saveUninitialized: false, }));

This is the minimum you need to do to get express-session working in a development environment. As discussed, the secret is used in hashing the session ID, to ensure it isn’t tampered with between the client and the server. This should be some very long, complex string that is hard to guess. This string should be rotated periodically to ensure that if it was compromised, it doesn’t stay that way long. The secret can also take an array of secrets to make it even harder to guess.

The resave option enforces that the session is resaved against the server store on each request, even if the session wasn’t modified. The saveUninitialized property forces a new session to be saved. Both the resave and saveUninitialized options are left to your discretion on how best to implement. Generally, saveUninitialized: false is used to reduce the session storage on the server for unauthenticated requests. resave is defaulted to true, but to reduce overhead you can set it to false if your store allows.

(Video) NodeJS Essentials 33: Express Sessions

Speaking of the store, you notice in this example you haven’t implemented one. The default server-side session storage is MemoryStore. According to the documentation, this is purposely not designed for production. This means it’s fine to leave the above code this way in development, but you should implement a different store in production. Not doing so can result in memory leaks and does not scale past a single process. A list of compatible session stores can be found here.

The following example uses express-sessions (note sessions instead of session) as a server-side store using MongoDB:

app.use( express.session({ secret: 'SomeSuperLongHardToGuessSecretString', resave: true, saveUninitialized: false, store: new (require('express-sessions'))({ storage: 'mongodb', instance: mongoose, host: 'localhost', port: 27017, db: 'test', collection: 'sessions', expire: 86400 })}));

Now your application will use your MongoDB instance to store the server session data. Express-sessions also supports a Redis implementation. Furthermore, there are many libraries for supporting other databases and in-memory solutions. Your stack will likely dictate what package you need to use.

Coming back to the security aspect of sessions, you learned that you should expire the session and the cookie. The example below builds on our working example to do just that.

app.use( express.session({ secret: 'SomeSuperLongHardToGuessSecretString', resave: true, saveUninitialized: false, store: new (require('express-sessions'))({ storage: 'mongodb', instance: mongoose, host: 'localhost', port: 27017, db: 'test', collection: 'sessions', expire: 86400 }), cookie: { maxAge: 2628000000 },}));
(Video) Node and Express - Sessions

In the above expression, only the session ID is stored in the cookie, so you can set the cookie.maxAge value to expire the session and the cookie in one shot. There is also an option for cookie.expires, however it is recommended that you set the maxAge option instead.

Now from your routes, you should be able to access the session object from your request object. Earlier you learned that you should regenerate your session after the user logs in. Let’s take a look at that using express and the ExpressOIDC from Okta.

const oidc = new ExpressOIDC({ issuer: {yourOktaDomain} + "/oauth2/default", client_id: {yourClientId}, client_secret: {yourClientSecret}, appBaseUrl: process.env.APP_BASE_URL, scope: "openid profile", routes: { login: { path: "/users/login", }, callback: { path: "/authorization-code/callback", }, loginCallback: { afterCallback: "/users/afterLogin", }, },});app.use(oidc.router);app.get("/users/afterLogin", ensureAuthenticated, (request, response, next) => { request.session.regenerate(function(err) { // will have a new session here })});

In the above example, you are registering the ExpressOIDC middleware provided by Okta to handle the login. After the successful login, you redirect the users to the users/afterLogin router, which then has access to the request object. Express-session has attached the session object to the request for you and you can use the session API to call regenerate. This will create a new session for the logged-in users.

Learn More

Session management is a topic that you could spend days researching and understanding. As I noted, the session management package you will use in Node.js will largely depend on your stack and your server framework. However, by becoming familiar with implementing safe and optimized session management in one framework, you can carry that knowledge to all other Node.js frameworks.

  • Why JWTs Suck as Session Tokens
  • Build a Simple CRUD Application with Node and MySQL
  • Build A Simple Web App with Node and Postgres

Make sure you follow us on Twitter and subscribe to our YouTube channel. If you have any questions, or you want to share what tutorial you’d like to see next, please comment below.


What is the session secret? ›

A session secret is a key used for encrypting cookies. Application developers often set it to a weak key during development, and don't fix it during production.

What is the difference between cookie session and express session? ›

Cookie session is basically used for lightweight session applications where the session data is stored in a cookie but within the client [browser], whereas, Express Session stores just a mere session identifier within a cookie in the client end, whilst storing the session data entirely on the server.

What is the difference between client session and express session? ›

Basically, express-session is more abstract, it supports different session stores (like files, DB, cache and whatnot). And client-session is a simple / lightweight cookie-based (cookie is the only storage engine supported: all the session info is stored on the client, in a cookie) session implementation.

How does session management work? ›

Session management refers to the process of securely handling multiple requests to a web-based application or service from a single user or entity. Websites and browsers use HTTP to communicate, and a session is a series of HTTP requests and transactions initiated by the same user.

How do I manage sessions in node JS? ›

To demonstrate session management in Node. js, we will create simple signup and sign-in application. Users will sign up for and sign in to this application by providing their email address and password. A session is created and saved in the Redis store for future requests when a user signs in.

What is the use of session in node JS? ›

Session Management in Node. js: Session Management is a technique that keeps track of users' states (data). If the client sends a request to the server then it is followed by HTTP protocol.

Can session work without cookies? ›

Normally session uses cookies to store data, but if cookies are disabled on browser setting then PHP sessions can also work without cookies.

Why use cookie instead of session? ›

The key difference between sessions and cookies is that sessions are saved on the server side while cookies are saved on the client side. Cookies are small text files used to store user information on the user's computer. Sessions are used to store user information on the user's server side.

Which is more secure session or cookie? ›

Session tokens have some advantages over cookies. They are more secure, as they are not exposed to XSS or CSRF attacks and can be encrypted or signed. They are also more performant, as they reduce the size of the request and response and allow stateless communication between the server and the browser.

What are the 3 types of sessions? ›

Sessions of Parliament
  • Budget session (February to May)
  • Monsoon session (July to September)
  • Winter session (November to December)

What are the two types of session management? ›

There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities.

What are the two types of session? ›

Binary versus Multiparty Session Types

Interaction between two processes can be checked using binary session types, while interactions between more than two processes can be checked using multiparty session types.

What is session management weakness? ›

So our first set of Session Management vulnerabilities relates to keeping the session identifier secret: Failure to use a cryptographically strong random value as the session identifier. If a session id value can be predicted, it need not be exposed for an attacker to hijack a session.

What are the benefits of session management? ›

Implementing proper session management usually increases the strength and security of the session token. And if you have not implemented it, then many vulnerabilities can be introduced with insecure session cookies that attackers can leverage to benefit an authenticated user session.

Why do we need session management? ›

Session management is used to facilitate secure interactions between a user and some service or application and applies to a sequence of requests and responses associated with that particular user.

Is session really anonymous? ›

Session keeps your communication private, secure, and anonymous. When using Session, your messages are sent to their destinations through a decentralised onion routing network similar to Tor (with a few key differences), using a system we call onion requests.

Is session app anonymous? ›

Session accounts are completely anonymous. No phone number or email required.

What is the difference between session key and secret key? ›

A session key is a secret key, but it is applicable to a web session. A secret key could apply to any type of encryption system - both symmetric and assymetric key algorithms have a secret key. Whether encrypting data at rest or data in transit, there will be secret keys.

What is a cookie secret? ›

The cookie secret is an encryption key, used to encrypt the browser cookies, which are used for authentication.


1. Randall Degges - Everything You Ever Wanted to Know About Web Authentication in Node
(The Nodejs Meetup)
2. Everything You Ever Wanted to Know About Authentication
3. Session vs Token Authentication in 100 Seconds
4. How To Manage User Roles In Node.js
(Web Dev Simplified)
5. Your complete guide to understanding the express-session library
(Zach Gollwitzer)
6. Sessions in Node #3 | Authentication in Node.js with Express and sessions | using Redis for sessions


Top Articles
Latest Posts
Article information

Author: Kerri Lueilwitz

Last Updated: 09/06/2023

Views: 5822

Rating: 4.7 / 5 (67 voted)

Reviews: 82% of readers found this page helpful

Author information

Name: Kerri Lueilwitz

Birthday: 1992-10-31

Address: Suite 878 3699 Chantelle Roads, Colebury, NC 68599

Phone: +6111989609516

Job: Chief Farming Manager

Hobby: Mycology, Stone skipping, Dowsing, Whittling, Taxidermy, Sand art, Roller skating

Introduction: My name is Kerri Lueilwitz, I am a courageous, gentle, quaint, thankful, outstanding, brave, vast person who loves writing and wants to share my knowledge and understanding with you.