Sessions: IDs, fixation, timeouts and logout

Asha clicks Log out on a shared computer and walks away. In the first program below, a copy of her session ID, taken from a log line, still opens her account 145 minutes later, because the app cleared her cookie and left its own record of the session alone. The fixed app answers the same request with a 401.

A session is the server’s memory that a run of requests belongs to one signed-in person, and its ID is the key to that memory. The key can be trusted when it is random and long, when sign-in replaces it, when time and logout end it, and when ending it deletes the server’s record. Each rule comes with a check that fails on the weak store and passes on the fixed one.

A session ID is a bearer secret, so the server must be able to end it

After a person signs in, the server stores a record of who they are and gives the browser an ID that names the record. The browser sends the ID with every request, and the server believes whoever sends it. The ID is a bearer secretbearer secret: A value that works for whoever presents it, with no proof that they are the one it was issued to. A session ID, an API key and an access token are bearer secrets: a copy is as good as the original., as good as the password for as long as the record exists. Step through one session, from the sign-in to a late copy of its ID:

The record in the table is the session, and four rules keep the table honest. Each has a part of this lesson to itself:

• The ID cannot be guessed. It holds at least 128 bits from a secure random generator, as ASVS 5.0.0 requirement 7.2.3 asks.
• Sign-in replaces the ID. A new ID at every sign-in means that an ID someone knew before it, a case of session fixationsession fixation: An attack on a session whose ID someone knew before the person signed in. If the app keeps that ID after the sign-in, whoever knew it holds a signed-in session. MITRE files it as CWE-384., opens nothing.
• Time ends the session. An idle limit and an absolute limit, both checked by the server against its own clock, end the sessions that nobody ended.
• Logout deletes the record. A logout, a disabled account and a sign out everywhere all delete the record, because clearing a cookie ends nothing on the server.

The OWASP Top 10 names three of these failures in its category A07:2025: an ID reused after sign-in, an ID in the URL, and sessions that a logout or a period of inactivity does not end.

Where the record lives is a choice as well: in a table the server keeps, or inside a signed cookie that the server cannot take back. The program gives two small apps the same five requests. Both ask the browser to drop the cookie at logout, and only one deletes its record:

// Two small apps keep sessions in a table. Both clear the cookie at logout; only one deletes its record.
// A request is answered 200 when its session ID is in the table and 401 when it is not. Neither app has a timeout,
// so the minute only labels the step.

function makeApp({ deletesRecordAtLogout }) {
  const sessions = new Map(); // session ID -> user
  return {
    signIn(user, id) {
      sessions.set(id, user);
      return 200;
    },
    get(id) {
      return sessions.has(id) ? 200 : 401;
    },
    logout(id) {
      // Either way the response says "Set-Cookie: sid=; Max-Age=0", so the person's browser forgets the ID.
      if (deletesRecordAtLogout) sessions.delete(id);
      return 204;
    },
  };
}

const weak = makeApp({ deletesRecordAtLogout: false });
const fixed = makeApp({ deletesRecordAtLogout: true });

// A copy of Asha's ID, such as one that a proxy wrote to a log line. In a real app the ID is 128 random bits.
const ID = 'Zk3rV9mQ-demo-id';

const steps = [
  [0, 'sign in as asha', (app) => app.signIn('asha', ID)],
  [5, 'GET /account with the cookie', (app) => app.get(ID)],
  [10, 'Asha clicks Log out', (app) => app.logout(ID)],
  [20, 'GET /account with the copied ID', (app) => app.get(ID)],
  [155, 'GET /account with the copied ID', (app) => app.get(ID)],
];

console.log('minute  request                           weak app  fixed app');
for (const [minute, what, run] of steps) {
  console.log(`${String(minute).padStart(6)}  ${what.padEnd(32)}  ${String(run(weak)).padStart(8)}  ${String(run(fixed)).padStart(9)}`);
}

minute  request                           weak app  fixed app
     0  sign in as asha                        200        200
     5  GET /account with the cookie           200        200
    10  Asha clicks Log out                    204        204
    20  GET /account with the copied ID        200        401
   155  GET /account with the copied ID        200        401

The weak app answered the copy with 200 at minute 20 and again at minute 155, which is 145 minutes after the logout, while the fixed app answered 401 both times. Neither app has a timeout, so the minute only labels the step: the weak app would have answered in the same way a year later.

Guessing an ID is a numbers game, and 128 random bits win it Pro: opens with a Pro, Premium or Ultimate pass