Sessions State keeping by the server


Under the name of sessions go various techniques for keeping a key-value storage associated to a client and controlled by the server.

  • Different from a simple client-based storage (cookies, storage API):

    • The client cannot insert/modify data without help from the server

    • (optional) Stored data are not visible to the client.

  • Typically short-lived:

    • Reduces risks associated to session hijacking/fixing.

Mechanics of a session system

  1. The client connects for the first time:

    • It is given a session identifier,
    • the server sets up a storage associated to the identifier.
  2. When the client visits again the site:

    • It transmits the session identifier
    • the server recovers the storage.
CLIENT SERVER GET / ?id=a434ef id=a434ef Sess a434ef user: toto loggedin: yes likes: oranges

Session identifiers

Many possible channels (any techniques used for keeping the state on the client):

  • URL (query string, path)
  • Hidden forms

    <input type="hidden" name="sessid" value="a3423f344">
  • Cookies (the most used one):

    Cookie: sessid=a3423f344
  • Storage API (with AJAX).

Security: session identifiers must be ephemeral, random and hard to guess.

Storage by the server

  • Possible storage areas:

    • volatile memory (RAM),
    • temporary file,
    • temporary database.
  • The server is the only one to see and modify data.

  • Potentially store large data (not recommended).

  • Default sessions system historically implemented in PHP (temporary file).

  • In Express:

Storage by the client

  • Leveraging the client local storage: cookies, storage API.

  • (Symmetric) cryptographic methods to guarantee

    • Confidentiality → Encryption: the server is the only one able to see the data.

    • Integrity → Signature (HMAC): the server is the only one able to create/modify data.

  • Session identifier = storage area.

  • Limited to small data.

  • The server must generate a random secret key, and never give it away.

  • In Express: cookie-session.

Express example

var express = require('express'),
    session = require('express-session');

app.use(session( {
  secret : '12345',
  resave: false,
  saveUninitialized: false,
} ));

app.get('/welcome', function (req, res) {
  req.session.user = req.query.user;       // Store data in the session

app.get('/next', function (req, res) {
  if (req.session.user) {                  // Retrieve data from the session
    res.end('Hello ' + req.session.user);
  } else {
    res.redirect('/welcome');              // If data is absent, redirect to /welcome

Sessions: pros/cons


  • Transparent API, hides the protocol and implementation details.
  • Often faster than querying a DB.


  • Uses more resources than a simple client-based storage.
  • Almost all implementations need the client to activate cookies.

Alternatives and complementary systems

Global storage for the application

  • Memory based key-value storages: Redis, …
  • Big table: Memcached, …

Security warnings

Never store unencrypted sensible data on the client
Never transmit them via the URL.
Always generate hard-to-guess session identifiers:
use random number generators and long strings, let identifiers depend on the HTTP(S) request.
Use an encrypted transport layer:
only use HTTPS for sensitive information (remember all personal information is sensitive).

An attacker with the ability to steal/fix session identifiers can acces all the user data.

Use short-lived sessions:
session cookies, identifiers, … must expire fast (or at least regularly).






Fork me on GitHub