DEV Community: Robert Domestisck

Stop Storing Secrets in localStorage: Patterns for a Secure Digital ID Wallet

Robert Domestisck — Sun, 26 Oct 2025 19:48:45 +0000

TL;DR: localStorage is convenient, but it’s a glass box. If you’re building a digital ID wallet app (cards, IDs, passes), move secrets out of JS-readable storage. Use passkeys/WebAuthn for auth, httpOnly cookies or a BFF for sessions, and E2EE with non-extractable keys + IndexedDB for encrypted payloads. Sprinkle in CSP, Trusted Types, and a service worker for defense-in-depth.

Why localStorage is the wrong place for secrets

XSS exfiltration: Any script that runs in your origin can read localStorage. That means one missed output-escape, compromised NPM dependency, or misconfigured third-party and your tokens are gone.

Long-lived & persistent: Secrets survive tabs, reloads, and crashes. Great for convenience, terrible for incident response.

No flags: Unlike cookies, you can’t mark localStorage as HttpOnly, Secure, or SameSite.

Copyable at rest: DevTools, extensions, or shared machines can yank it.

What counts as a “secret”?
Access/refresh tokens, private keys, recovery seeds, raw PII, and unencrypted ID documents (images, PDFs, MRZ text). If losing it lets an attacker impersonate a user or decrypt their vault, it’s a secret.

Threat model for a Digital ID Wallet

Goal: store user cards/IDs encrypted at rest, unlock with the user’s device auth, and sync safely.

Trust boundaries: the server must never see plaintext vault data; the browser must not keep extractable keys in JS land.

Reality: XSS, supply-chain JS, malicious extensions, shoulder-surfing, stolen laptops.

So we need patterns that degrade gracefully even when XSS happens.

Pattern 1 — Authenticate with Passkeys (WebAuthn), not bearer tokens in JS

Use WebAuthn to create a device-bound credential. No tokens to hoard in localStorage.

// Register (create) a passkey
const publicKey: PublicKeyCredentialCreationOptions = {
challenge: await fetch('/webauthn/challenge').then(r => r.arrayBuffer()),
rp: { name: 'Your App', id: location.hostname },
user: {
id: new TextEncoder().encode(currentUserId),
name: currentUserEmail,
displayName: currentUserName,
},
pubKeyCredParams: [{ alg: -7, type: 'public-key' }, { alg: -257, type: 'public-key' }],
authenticatorSelection: { userVerification: 'required' },
};
const cred = await navigator.credentials.create({ publicKey });
await fetch('/webauthn/register', {
method: 'POST',
body: JSON.stringify(cred),
headers: { 'Content-Type': 'application/json' }
});

At sign-in, assert instead of exchanging passwords for bearer tokens:

const assertion = await navigator.credentials.get({
publicKey: {
challenge: await fetch('/webauthn/challenge').then(r => r.arrayBuffer()),
userVerification: 'required',
allowCredentials: [ /* your credential IDs */ ]
}
});
await fetch('/webauthn/verify', { method: 'POST', body: JSON.stringify(assertion) });

Session handling: Prefer an opaque, short-lived session issued server-side, returned as Set-Cookie with HttpOnly; Secure; SameSite=Strict. No token lands in JS.

Pattern 2 — Use a BFF (Backend-for-Frontend) instead of storing tokens client-side

If you must talk to third-party APIs, don’t hand access tokens to the browser. Let a thin BFF attach tokens server-side.

Browser -> BFF (/api/*) -> Upstream APIs
^ keeps only HttpOnly session cookie, no access tokens in JS

This removes the incentive to stash OAuth tokens in localStorage. When XSS fires, there’s nothing reusable to steal.

Bonus: If you need proof-of-possession, add DPoP at the BFF or mutual TLS upstream.

Pattern 3 — Encrypted vault in IndexedDB using non-extractable keys

Store encrypted cards/IDs in IndexedDB. The encryption key is a non-extractable CryptoKey wrapped by a passkey-protected key. Even if XSS lists your DB, it sees only ciphertext.

Step A: Create a content-encryption key (CEK)
// Non-extractable symmetric key
const cek = await crypto.subtle.generateKey(
{ name: 'AES-GCM', length: 256 },
false, // not exportable
['encrypt', 'decrypt']
);

Step B: Wrap CEK with a user-bound key

Use a wrapping key tied to the device (via WebAuthn + platform keystore) or derive from a user secret combined with device signals. Here’s the Web Crypto wrap flow (assuming you obtained/imported wrappingKey securely):

const wrapped = await crypto.subtle.wrapKey(
'raw',
cek,
wrappingKey, // e.g., RSA-OAEP/WebAuthn-backed
{ name: 'RSA-OAEP' }
);
// Save wrapped in IndexedDB; unwrap it after user verification

Step C: Encrypt and store records
async function encryptBlob(cek: CryptoKey, data: Uint8Array) {
const iv = crypto.getRandomValues(new Uint8Array(12));
const ct = await crypto.subtle.encrypt(
{ name: 'AES-GCM', iv },
cek,
data
);
return { iv, ct: new Uint8Array(ct) };
}

Persist { iv, ct } in IndexedDB. Never keep plaintext or keys in localStorage.

Pattern 4 — Gate decryption behind User Verification (biometrics/PIN)

On each unlock, require userVerification: 'required' via WebAuthn (or OS keychain on desktop apps). This makes decryption events interactive and ties them to Face/Touch ID.

await navigator.credentials.get({
publicKey: {
challenge: await fetch('/unseal/challenge').then(r => r.arrayBuffer()),
userVerification: 'required',
allowCredentials: [ /* the credential used to wrap CEK */ ]
}
});
// server returns a one-time unwrap token or a wrapped CEK shard

Practical note: Cache a short-lived unwrapped CEK in memory only (not in storage). Clear it on tab close, inactivity, or lock.

Pattern 5 — Service Worker as a thin shield

A service worker can centralize fetches and enforce “no secrets in requests”:

// sw.js
self.addEventListener('fetch', (e) => {
const url = new URL(e.request.url);
// Block accidental leakage of internal headers/query params
if (url.searchParams.has('token')) {
e.respondWith(new Response('Forbidden', { status: 403 }));
return;
}
e.respondWith(fetch(e.request));
});

It also provides offline caching of encrypted payloads only (Cache Storage). Never cache decrypted responses.

Pattern 6 — Lock down the front end (CSP, Trusted Types, COOP/COEP)

CSP: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-...'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'.

Trusted Types: eliminate DOM XSS sinks by requiring safe HTML builders.

Subresource Integrity: pin hashes for third-party JS (or better: self-host and sign).

COOP/COEP: isolate your browsing context to reduce cross-origin surprises and enable powerful APIs safely.

These won’t save you if you actively store secrets in JS storage, but they reduce XSS probability and blast radius.

Pattern 7 — Sync without trusting the server (E2EE)

For multi-device:

Generate CEK on Device A.

Wrap CEK using Device A’s wrapping key; upload only the wrapped blob.

On Device B, after user verification, re-wrap CEK for Device B and store locally.

Documents sync as ciphertext; the server never sees plaintext or unwrapped CEKs.

If you add multi-party access (e.g., family vault), use asymmetric envelope encryption: a unique data key per item, wrapped for each member’s public key.

Pattern 8 — Mobile & desktop: use platform keychains

If you ship native shells (Capacitor, React Native, desktop apps):

iOS: Keychain + Secure Enclave (non-exportable keys).

Android: Keystore with StrongBox where available.

Desktop: OS keyrings (Windows DPAPI, macOS Keychain, libsecret on Linux).

Store wrapped keys or small secrets there, never plaintext in sandboxed files.

What if you really need to remember something in the browser?

If you must persist some state:

Store opaque references or nonces, not secrets.

Use short expiry and bind them to device/credential where possible.

Rotate aggressively; treat it like a cache hint, not a keyring.

Migration playbook (away from localStorage)

Audit: find every read/write of localStorage, list the data classes (token, PII, UI prefs).

Classify: move only non-sensitive prefs (theme, layout) to localStorage; everything else migrates.

Session: swap JS bearer tokens for HttpOnly session cookies via a BFF.

Vault: introduce IndexedDB + non-extractable keys; write a one-time migration that decrypts old blobs and re-encrypts under the CEK.

App hardening: deploy CSP + Trusted Types; turn on SRI; review third-party scripts.

Kill switch: add a remote feature flag to force logout + key wipe for incident response.

Mini reference: Do / Don’t

HttpOnly; Secure; SameSite cookies for sessions

WebAuthn passkeys for auth + user verification

Non-extractable keys + AES-GCM in IndexedDB

E2EE sync (server sees ciphertext only)

CSP, Trusted Types, SRI, SW hygiene

Don’t

Put tokens, private keys, or vault plaintext in localStorage

Cache decrypted data in service worker/Cache Storage

Log secrets to console/analytics

Rely on obfuscation or UI-level “locks” as real security

Closing thoughts

A digital ID wallet lives or dies by how you store secrets. localStorage was never meant to be a key vault. With passkeys for sign-in, server-side sessions (or a BFF), and an encrypted vault backed by non-extractable keys in IndexedDB, you raise the bar dramatically—without wrecking UX. Add platform keychains on mobile/desktop, and you’ve got a modern, user-friendly wallet that stays locked even when the browser misbehaves.

If you want a follow-up, I can post a small reference implementation: WebAuthn login + CEK wrapping + encrypted IndexedDB with React hooks and a service worker cache that never touches plaintext.

5 Lessons from Web Development That Apply to People-Finder Platforms

Robert Domestisck — Thu, 31 Jul 2025 09:29:37 +0000

What do building a React app and reconnecting with a childhood friend have in common?

At first glance, not much. One involves component trees and state management; the other, years of distance and a lingering question: "What ever happened to them?" But look closer, and you’ll find that both share something powerful—code designed to connect people.
People-finder platforms like Radaris help users track down old friends, classmates, family members, or long-lost loved ones. Whether you’ve moved across states or simply drifted apart over time, platforms like these turn fragmented data—addresses, phone numbers, public records—into meaningful reconnections. They’re part search engine, part digital detective.

And they don’t work by accident. The tech principles that power great web applications—speed, structure, security, and user-centered design—are the same ones that make people-finders so effective. Web development isn’t just about building tools for businesses—it’s about building bridges between people.

Lesson 1: Speed Matters More Than Ever

In web development, speed isn't just a bonus—it's survival. Studies show that users start bouncing if a page takes more than 2–3 seconds to load. That urgency only intensifies on platforms driven by emotion. People-finder tools like Radaris.com aren't just utilities—they’re emotional engines. When you're trying to reconnect with someone who disappeared from your life years ago, waiting isn’t just frustrating—it’s heartbreaking.

That’s why performance optimization is critical. Platforms like Radaris leverage:

Indexed search to surface results faster than traditional database queries
Smart caching to avoid reloading previously visited profiles
Lazy loading to prioritize content visibility without overloading the page

📌 Callout: “At Radaris, milliseconds matter when you're searching for someone who’s been missing for years.”

Lesson 2: User Experience is Everything

Speed gets users in the door, but user experience earns their trust. Clunky interfaces breed hesitation, especially when someone’s emotionally invested in the outcome. On the other hand, a fluid, intuitive design helps users feel confident—and keeps them engaged.

For people-finder platforms, that means:

Search-as-you-type to show instant feedback and reduce typing errors
Mobile-first UI for users looking up names from their phones at a family gathering
Contextual breadcrumbs that help users trace their search journey without confusion

Radaris excels at this with a clean, responsive layout, logical filtering options, and CTAs that guide without overwhelming. When someone is nervous about finding the right person, clarity becomes comfort.

Trust isn't a feature—it’s the byproduct of thoughtful design.

Lesson 3: Data Integrity is a Feature, Not a Footnote

In web development, clean, structured, and normalized data is the foundation of any stable app. If your database is a mess, no amount of front-end magic can fix it. The same is even more critical in people-finder platforms like Radaris.

When you're helping users reconnect with someone from their past, a wrong address or mismatched name isn’t just a technical hiccup—it’s a broken lead or false hope. That’s why data integrity isn’t a backend concern—it’s a core feature.

Behind the scenes, platforms like Radaris rely on:

Deduplication algorithms to avoid showing the same person multiple times
Validation rules to flag incomplete or suspicious entries
Source hierarchy to prioritize the most credible data sets

The challenge? Balancing data volume with verification. Pulling from multiple public records, social networks, and third-party databases requires strict logic to determine what’s real and what’s noise.

🛠️ People-finders aren’t just aggregators—they’re data curators.

Lesson 4: Privacy by Design

The old mindset was “gather everything.” In 2025, the mantra is “protect everything.”

Privacy isn’t a checkbox—it’s a design principle. With increasing scrutiny from users and regulators, platforms like Radaris are embedding privacy directly into the product lifecycle.

That means compliance with laws like GDPR and CCPA isn’t optional—it’s fundamental. But technical compliance is just one side of the coin. The developer’s role is to operationalize privacy:

Building granular permission layers that control who sees what
Creating opt-out workflows that are user-friendly and effective
Securing data with encrypted endpoints and robust access controls

🔐 “Building trust starts in the codebase.” When users feel that their data is respected and protected, they’re far more likely to engage—and stay.

Lesson 5: Empowering Users with Insight, Not Overload

In development, we know the difference between a great dashboard and a terrible one. The best ones highlight what matters; the worst ones bury users in data. That same principle is crucial in people-finder platforms.

When someone searches for a long-lost friend or relative, they don’t want a data dump. They want clarity. A smart interface prioritizes information like:

Last known location
Past occupations
Possible relatives
Relevant age or education markers

This isn’t just a UI challenge—it’s a UX responsibility. Overloading users with raw data can create anxiety or confusion, especially when it comes to sensitive subjects like reconnecting after years apart.

Good platforms use design patterns that support progressive disclosure to surface the most relevant details first, offer intuitive filters, and encourage thoughtful outreach, not invasive digging.

📌 Ethical UX means empowering, not overwhelming.

Conclusion: Building With Empathy

In the world of people-finder tools, web development isn't just about performance or architecture—it's about people.

Your choices as a developer—from how fast a page loads to how data is displayed or protected—shape how someone experiences that crucial moment of reconnection. It's not just about using the latest tech stack or building the slickest UI.

💡 “When you're building tools that help someone reconnect with a person they lost touch with, clean code and fast endpoints aren’t just nice-to-haves—they're acts of service.”

That’s why privacy-by-design frameworks aren’t just compliance checkboxes—they’re trust-building tools. It’s also why people-finder tools must focus on data accuracy as a product feature, not an afterthought.

In the end, great platforms blend engineering skill with emotional intelligence—and that’s where the magic really happens.