A session object often holds more than a counter — user email, role and permissions, even error messages. The moment it contains personal data like PII or PHI, two responsibilities follow: stopping attackers from stealing the session, and keeping that personal data out of harm’s way if they do.

If your company serves European customers, GDPR compliance is non-negotiable, wherever you are hosted. This article covers secure session storage from both angles — the security mechanics that keep sessions out of attackers’ hands, and the data practices that stop a stolen session from becoming a breach.

Is session data personal data under GDPR?

It depends on what’s inside. A bare, random session ID is just an index into your server’s store and usually isn’t personal data on its own. But the session object it points to often holds emails, names, or permissions tied to an individual — and that is personal data, which brings GDPR’s integrity and confidentiality principle into play: you must protect it with appropriate security measures.

Session security fundamentals

Most session breaches come down to a handful of missed basics. Stay ahead of attackers by getting these right (OWASP’s session cheat sheet is the canonical reference):

• Keep session data server-side. Hold it in a protected server-side store — never put PII, session IDs, or tokens in browser localStorage or sessionStorage.
• Use strong session IDs. Long, unpredictable, and generated by a cryptographically secure random source.
• Set the cookie flags. Secure (HTTPS only), HttpOnly (no JavaScript access, blunting XSS), and SameSite (blunting CSRF).
• Expire sessions. Apply both an idle timeout and an absolute lifetime, and invalidate on the server as well as the client at logout.
• Regenerate the ID on login. Issuing a fresh session ID after authentication defeats session-fixation attacks.

Do session cookies need consent?

Generally no. Strictly necessary session cookies — the kind that simply keep a user logged in — are exempt from prior consent under GDPR and the ePrivacy rules. You should still be transparent about what you store and why, but the session itself doesn’t need a consent banner.

Do you need to encrypt session data?

There is no explicit GDPR encryption mandate, but the regulation repeatedly names encryption and pseudonymization as “appropriate technical and organizational measures.” Combined with the duty of data protection by design and by default, that makes encrypting — or, better, removing — personal data in sessions the obvious move.

Store sessions securely with Databunker

Databunker is a secure vault for personal records, PII, and PHI that doubles as an encrypted session store. Your application keeps only a session ID, while the contents are encrypted at rest and access-controlled. Databunker Pro backs session storage with Redis; the open-source engine uses its SQL database (SQLite, MySQL, or PostgreSQL) — either way the data never sits in plaintext.

The stronger pattern is to keep PII out of the session altogether: store the profile in the vault and place a token in the session. Then even a hijacked session exposes a token, not your customer — the same idea behind GDPR-compliant logging and a data privacy vault. See also pseudonymization vs anonymization and PII tokenization.

Node.js quick start

The databunkerpro-js SDK talks to Databunker Pro’s session API directly — open, read, and invalidate encrypted sessions, each with its own expiration:

1

npm install databunkerpro-js

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

const express = require('express');
const cookieParser = require('cookie-parser');
const { v4: uuidv4 } = require('uuid');
const DatabunkerproAPI = require('databunkerpro-js');

const api = new DatabunkerproAPI(
  process.env.DATABUNKERPRO_URL,   // e.g. https://pro.databunker.org
  process.env.DATABUNKERPRO_TOKEN  // your access token
);

const app = express();
app.use(cookieParser());

// On login: open an encrypted, auto-expiring session in Databunker Pro
app.post('/login', async (req, res) => {
  const sessionuuid = uuidv4();

  // Store a vault token and minimal claims — never raw PII
  await api.upsertSession(
    sessionuuid,
    { userToken: req.userToken, role: 'basic-user' },
    { finaltime: '30m' } // absolute expiry; use slidingtime to extend on activity
  );

  res.cookie('sid', sessionuuid, { httpOnly: true, secure: true, sameSite: 'strict' });
  res.send('Logged in');
});

// On each request: read the session back
app.get('/me', async (req, res) => {
  const sid = req.cookies.sid;
  if (!sid) return res.status(401).send('No session');

  const session = await api.getSession(sid); // stops resolving once it expires
  if (!session) return res.status(401).send('Session expired');

  res.json(session);
});

// On logout: invalidate server-side, not just the cookie
app.post('/logout', async (req, res) => {
  if (req.cookies.sid) await api.deleteSession(req.cookies.sid);
  res.clearCookie('sid');
  res.send('Logged out');
});

app.listen(3200, () => console.log('Listening on http://localhost:3200'));

upsertSession, getSession, and deleteSession map to Pro’s SessionUpsert / SessionGet / SessionDelete API; use listUserSessions to enumerate — and revoke — every active session for one user. See the Databunker Pro documentation for the full API and SDKs in PHP, Python, and Java.

Summary

Secure session storage is two jobs: lock it down so attackers can’t take it, and keep personal data out so a stolen session isn’t a reportable breach. Get the OWASP basics right, encrypt what remains, and let Databunker hold the PII — with a few lines of code your sessions are private and secure by design.

Frequently asked questions

Is session data personal data under GDPR? If the session holds emails, names, or other identifiers, yes. A bare random session ID, on its own, usually isn’t.

Do session cookies need consent? Strictly necessary session cookies are exempt from prior consent, though you should still disclose them.

Should I encrypt session data? GDPR doesn’t mandate it by name, but lists encryption and pseudonymization as appropriate measures — so encrypt it, or keep PII out of the session entirely.

Where should session data live? Server-side, in a protected store — never in browser localStorage or sessionStorage.