FIDO Device-Bound Session Credentials (DBSC) Hardware Token Invariant

Q: How does adopting this rule prevent AI hallucinations?

This rule explicitly declares what the AI must avoid (Relying on Unbound Bearer Session Cookies Vulnerable to Exfiltration and Replay Attacks) and prescribes verified positive examples. Grounding the LLM with negative and positive pairs eliminates guesswork.

Q: Which AI coding environments are supported?

This specification is multi-platform compatible: Cursor (.cursor/rules/*.mdc & .cursorrules), Anthropic Claude Code (CLAUDE.md), Windsurf (.windsurfrules), Codex / Cline (AGENTS.md), and GitHub Copilot (.github/copilot-instructions.md).

Q: Can I combine this rule with other technology stacks?

Yes. Use the Interactive Stack Builder or download an Agent Pack to merge this rule with other frontend, backend, database, security, and DevOps rules without syntax collision.

FIDO Device-Bound Session Credentials (DBSC) Hardware Token Invariant

--- description: FIDO Device-Bound Session Credentials (DBSC) Hardware Token Invariant - Enforces cryptographic binding of HTTP session credentials to client-side hardware keystores (TPM 2.0 or Apple Secure Enclave) according to the W3C/IETF Device-Bound Session Credentials (DBSC) specification. Eliminates infostealer malware extraction and adversary-in-the-middle session hijacking by issuing ultra short-lived transactional cookies that can only be refreshed via hardware-signed proof-of-possession challenges. globs: src/auth/**/*.{ts,tsx}, src/middleware/**/*.{ts,tsx}, src/server/**/*.{ts,tsx}, src/api/**/*.{ts,tsx} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/fido-dbsc-session-binding-guardrail" --- # FIDO Device-Bound Session Credentials (DBSC) Hardware Token Invariant > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Relying on Unbound Bearer Session Cookies Vulnerable to Exfiltration and Replay Attacks ## System Constraints You are a Principal Security Architect enforcing FIDO Device-Bound Session Credentials (DBSC) standards. Mandate that all high-privilege session cookies have an ephemeral TTL (maximum 15 minutes) and are strictly refreshed through cryptographic challenge-response protocols anchored to client-side hardware TPM/Secure Enclave keys. Reject any architectural attempt to grant long-lived bearer tokens or to treat session validation purely as an opaque database lookup without hardware proof-of-possession. ## Strict Guidelines - Engineers MUST ALWAYS enforce the DBSC registration handshake, validating client public key parameters (ES256, Ed25519, or RS256) and storing the public key bound to the immutable session record. - Engineers MUST NOT issue long-lived ambient bearer cookies; application session cookies MUST have a lifetime not exceeding 15 minutes, relying on DBSC background refresh to maintain continuous user sessions. - Services MUST issue a cryptographically random, single-use, high-entropy challenge via the 'Sec-Session-Challenge' HTTP header whenever a session refresh is triggered. - Code SHOULD verify the signed JWT in the 'Sec-Session-Response' header against the registered hardware public key, validating nonce freshness, timestamp skew (<= 30s), audience, and the bound session identifier. - Components NEVER accept session credentials transferred across distinct device fingerprints or with invalid proof-of-possession signatures; any verification failure MUST immediately invalidate the parent session cluster. ## Bad vs Good Implementations ### DBSC Refresh Endpoint: Insecure Bearer Refresh vs. Hardware-Bound Proof-of-Possession #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: The session refresh depends entirely on an ambient, bearer refresh cookie. If malware or an adversary-in-the-middle exfiltrates the cookie from the user's browser storage or memory, they can replay it from any host without hardware verification. ```typescript import { Request, Response } from 'express'; import { db } from '../db'; // ANTI-PATTERN: Traditional bearer refresh vulnerable to infostealers export async function refreshSession(req: Request, res: Response) { const refreshToken = req.cookies['refresh_token']; if (!refreshToken) { return res.status(401).json({ error: 'Missing refresh token' }); } // Stolen refresh token from file system / memory can be used anywhere const session = await db.sessions.findUnique({ where: { token: refreshToken } }); if (!session || session.expiresAt < new Date()) { return res.status(401).json({ error: 'Invalid or expired session' }); } // Re-issuing new cookies without proof of hardware possession const newAccessToken = crypto.randomUUID(); res.cookie('access_token', newAccessToken, { httpOnly: true, secure: true }); return res.status(200).json({ status: 'refreshed' }); } ``` #### Production Standard (Correct) > **Standard**: Implements the W3C/IETF DBSC protocol by verifying a signed JWT originating from the client's TPM or Secure Enclave. Validates single-use challenges, cryptographic signatures, and expiration before issuing a short-lived session cookie, neutralizing stolen cookies. ```typescript import { Request, Response } from 'express'; import * as jose from 'jose'; import { db } from '../db'; import { verifyAndBurnNonce } from '../security/nonce'; // PRODUCTION FIX: Cryptographically bound DBSC session refresh export async function refreshBoundSession(req: Request, res: Response) { const sessionId = req.headers['sec-session-id'] as string; const sessionResponseJwt = req.headers['sec-session-response'] as string; if (!sessionId || !sessionResponseJwt) { return res.status(400).json({ error: 'DBSC headers missing' }); } const session = await db.deviceBoundSessions.findUnique({ where: { id: sessionId }, select: { publicKeyJwk: true, status: true, userId: true } }); if (!session || session.status !== 'ACTIVE') { return res.status(401).json({ error: 'Session revoked or invalid' }); } try { // Parse registered hardware public key (TPM / Secure Enclave) const publicKey = await jose.importJWK(JSON.parse(session.publicKeyJwk), 'ES256'); // Verify JWT signature generated by the device's hardware enclave const { payload } = await jose.jwtVerify(sessionResponseJwt, publicKey, { algorithms: ['ES256'], audience: 'https://auth.example.com/dbsc/refresh', maxTokenAge: '30s' }); // Enforce single-use challenge consumption to prevent replay const challenge = payload['jti'] as string; const isNonceValid = await verifyAndBurnNonce(sessionId, challenge); if (!isNonceValid) { await db.deviceBoundSessions.update({ where: { id: sessionId }, data: { status: 'COMPROMISED' } }); return res.status(403).json({ error: 'Replay detected. Session terminated.' }); } // Issue short-lived transactional cookie (max 15 mins) const shortLivedToken = await generateShortLivedJwt(session.userId, sessionId, 900); res.setHeader('Set-Cookie', `session_token=${shortLivedToken}; HttpOnly; Secure; SameSite=Strict; Max-Age=900; Path=/`); return res.status(200).json({ status: 'refreshed' }); } catch (err) { return res.status(401).json({ error: 'Cryptographic proof-of-possession failed' }); } } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: FIDO Device-Bound Session Credentials (DBSC) Hardware Token Invariant

FIDO Device-Bound Session Credentials (DBSC) Hardware Token Invariant defines an industrial-grade behavioral standard for security engineering. Enforces cryptographic binding of HTTP session credentials to client-side hardware keystores (TPM 2.0 or Apple Secure Enclave) according to the W3C/IETF Device-Bound Session Credentials (DBSC) specification. Eliminates infostealer malware extraction and adversary-in-the-middle session hijacking by issuing ultra short-lived transactional cookies that can only be refreshed via hardware-signed proof-of-possession challenges. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Relying on Unbound Bearer Session Cookies Vulnerable to Exfiltration and Replay Attacks Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Relying on Unbound Bearer Session Cookies Vulnerable to Exfiltration and Replay Attacks	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS enforce the DBSC registration handshake, validating client public key parameters (ES256, Ed25519, or RS256) and storing the public key bound to the immutable session record.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.