How to Stop Stolen Session Cookies in Node.js using Device Bound Session Credentials (DBSC)

Suliman Abdulrazzaq — Sun, 24 May 2026 22:39:56 +0000

Web applications still rely heavily on session cookies — and that creates a serious security problem:

If a session cookie gets stolen (via XSS, malware, logs, or proxy leaks), it can often be replayed from another device with no resistance.

This is exactly the gap that Device Bound Session Credentials (DBSC) aims to solve.

DBSC is a W3C specification that binds a session to a device-held cryptographic key instead of treating cookies as pure bearer tokens.

In this article, I’ll show a practical Node.js implementation using dbsc-toolkit, an open-source library that brings DBSC support to real-world backend frameworks.

🔐 What DBSC Changes

Traditional cookies:

Whoever has the cookie → owns the session

DBSC model:

Session is tied to a device key (TPM / Secure Enclave / WebCrypto fallback)
Stolen cookies alone are useless on another device
Server verifies proof of device possession on requests
⚙️ What dbsc-toolkit provides

dbsc-toolkit is a Node.js implementation of DBSC with:

Session registration flow
Challenge / response verification
Session binding + validation
Express / Fastify / Hono / Next.js support
Redis / PostgreSQL / Memory storage adapters
Optional Web Crypto fallback for non-Chromium browsers
🚀 Quick Example (Express)
import express from "express";
import { randomUUID } from "node:crypto";
import { createDbsc } from "dbsc-toolkit/express";
import { MemoryStorage } from "dbsc-toolkit/storage/memory";

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

const dbsc = createDbsc({ storage: new MemoryStorage() });
dbsc.install(app);

app.post("/login", async (req, res) => {
await dbsc.bind(res, randomUUID(), { userId: req.body.username });
res.json({ ok: true });
});

app.get("/me", (req, res) => {
res.json(res.locals.dbsc);
});

app.listen(3000);
🧪 Why this matters

Most modern auth systems still rely on bearer-based sessions (cookies or JWTs).

That means:

XSS → session theft
logs → session leakage
proxy leaks → replay attacks
malware → full account takeover

DBSC changes the model from:

"Who has the token?"

"Who owns the device that can prove the key?"

🌐 Compatibility

dbsc-toolkit works with:

Node.js (Express, Fastify, Hono, Next.js)
Chrome (native DBSC on supported versions)
Firefox / Safari (WebCrypto fallback)
Redis / PostgreSQL / Memory storage
📦 Repository

https://github.com/SulimanAbdulrazzaq/dbsc-toolkit

💬 Notes

This project is based on the current W3C DBSC specification and is intended for experimentation, prototyping, and early adoption in Node.js authentication systems.

Feedback, security review, and spec alignment suggestions are welcome.

I built an AI agent that understands your AWS infrastructure

Suliman Abdulrazzaq — Sun, 08 Mar 2026 11:41:01 +0000

Most teams managing AWS today don't rely on the CLI directly anymore.

Instead, infrastructure is usually managed using Infrastructure as Code (IaC) tools like Terraform, Pulumi, or CloudFormation.

IaC is great for defining infrastructure because it provides:

reproducibility
version control
predictable deployments

But even with IaC, engineers still face operational tasks like:

investigating infrastructure issues
understanding relationships between resources
making quick changes during incidents
handling repetitive operational tasks

These tasks often require jumping between the AWS console, documentation, logs, and infrastructure definitions.

That made me wonder:

What if an AI agent could understand your AWS infrastructure and help with those operational workflows?

So I built Zesky AI.

You can see it here:
https://zeskyai.com

Not a replacement for IaC

Tools like Terraform or Pulumi remain the best way to define infrastructure.

Zesky AI is not meant to replace IaC or the AWS console.

Instead, the goal is to assist with operational workflows around infrastructure.

Think of it more like an AI DevOps assistant that helps engineers understand and safely interact with their cloud environments.

How it works

Instead of navigating multiple dashboards or writing commands, you describe what you want in plain English.

Example:

"Open port 443 for my web server"

The system will:

scan your AWS resources
identify the relevant instance and security group
check existing rules
propose the correct change
wait for your approval before executing

The key idea is that the system analyzes the infrastructure first before suggesting any action.

Why the resource-first approach matters

Many AI tools generate commands without understanding the real infrastructure.

But cloud environments are complex, and running the wrong command can break production systems.

That’s why the agent first analyzes resources such as:

EC2 instances
security groups
networking rules
VPC relationships

Only after understanding the environment does it suggest an action.

Example scenarios

Some situations where this might be useful:

investigating which security groups expose public ports
quickly allowing HTTPS access during deployment
understanding infrastructure relationships
performing repetitive operational tasks

Instead of navigating several AWS pages, the agent analyzes the environment and proposes the correct action.

You still review and approve everything before it runs.

Looking for feedback

Right now I'm mostly trying to understand one thing:

Would something like this actually be useful for AWS engineers?

If you work with AWS, DevOps, or cloud infrastructure, I’d really appreciate your feedback.

What kinds of infrastructure tasks do you find the most repetitive or time-consuming?