CSRF is Dead, Long Live Request Intent: The Anatomy of a Cryptographic Primitive

---

The "Synchronizer Token Pattern"—the standard approach to CSRF protection for the last decade—is becoming an architectural liability. In an era of serverless runtimes, edge computing, and distributed systems, relying on a stateful session store (like Redis) just to validate a form submission is an inefficiency we should no longer accept.

I am developing Sigil, not as another middleware framework, but as a stateless cryptographic primitive. It redefines CSRF protection from a "token check" into a mathematical verification of Request Intent.

This article details the engineering constraints, the cryptographic architecture, and the specific security pain points Sigil addresses without the bloat of traditional frameworks.

1. The Pain Points of Stateful Security

Most existing CSRF solutions suffer from three fundamental engineering flaws:

1. State Dependency (The I/O Tax): Traditional middleware checks a token against a session store. This introduces network I/O latency (~1-5ms) to every state-changing request. In edge environments, this dependency is crippling.

2. Context Blindness: A token is valid if it exists. Most libraries do not cryptographically bind the token to the specific user session, origin, or action, leaving them vulnerable to token exfiltration and reuse.

3. False Security via "Middleware": Many libraries couple validation logic with HTTP framework semantics (Express/Fastify objects), making the core logic untestable in isolation and impossible to port to non-Node runtimes (Bun, Deno, Workers).

2. The Formula: Request Intent Verification

Sigil abandons the "filter" model in favor of a proof model. A request is not valid simply because a token is present. Validity is defined by a logical conjunction of four dimensions:

ValidRequest = Integrity & Context & Freshness & Provenance

• Integrity: The token has not been tampered with (HMAC-SHA256).

• Context: The token is cryptographically bound to a specific session or user entity (Context Hash).

• Freshness: The token is within its Time-to-Live (TTL) and, for critical actions, has not been replayed.

• Provenance: The request originates from a trusted source (Origin/Fetch Metadata).

If any variable in this equation resolves to false, the request is rejected.

3. Engineering Decisions & Cryptographic Architecture

To implement this formula without external state, strictly defined engineering constraints were applied.

3.1. Zero-Dependency & WebCrypto

Sigil rejects the Node.js crypto module and node-gyp dependencies. It relies exclusively on the WebCrypto API.

• Why: This ensures the primitive is runtime-agnostic (Node 18+, Bun, Deno, Cloudflare Workers) and utilizes native, constant-time cryptographic implementations provided by the host environment.

3.2. HKDF Key Hierarchy

Using a single "secret key" is insufficient for modern threat models. Sigil utilizes HKDF-SHA256 (RFC 5869) to derive a key hierarchy from a master secret.

• Domain Separation: Keys are derived separately for different scopes (csrf, oneshot, internal). A leak in the CSRF key scope does not compromise the internal signing keys.

• Rotation: We utilize a Keyring model (Active + Previous keys) identified by an 8-bit kid (Key ID), allowing for key rotation without downtime.

3.3. Deterministic "Single Failure Path"

A common vulnerability in security libraries is the Timing Attack via early returns. If a library returns false immediately upon parsing a bad token, an attacker can infer the validity of the structure based on response time.

Sigil implements a Single Failure Path.

Regardless of whether the token is malformed, expired, or has an invalid signature, the execution time remains constant. All validation steps—parsing, TTL check, HMAC verification—are executed. The boolean result is computed at the very end.

4. The One-Shot Primitive: Solving Replay

For high-assurance actions (e.g., POST /transfer-funds, DELETE /account), a standard Time-based One-Time Password (TOTP) or standard CSRF token is insufficient because it remains valid for its entire TTL window (e.g., 20 minutes).

Sigil introduces the One-Shot Token:

OneShot = HMAC(k, nonce || timestamp || action\_hash || context)

1. Action Binding: The token is valid only for a specific endpoint (e.g., SHA-256("POST:/admin/delete")). It cannot be repurposed for other actions.

2. Ephemeral Nonce Cache: To prevent replay, Sigil uses a strictly bounded LRU cache for nonces. This is the only stateful component, but it is ephemeral (memory-only) and fails-open if necessary.

5. Security Boundaries (Brutal Honesty)

Sigil is a primitive, not a silver bullet. We must define what it does not do:

• It is not a WAF: It does not filter traffic based on IP or heuristics.

• It does not prevent XSS: If an attacker has XSS, they can read the token and bypass CSRF protection. (Sigil mitigates the blast radius via Context Binding, but XSS is a separate domain).

• It provides no Authentication: It assumes the user is already authenticated via other means.

Conclusion

We need to stop treating security as a "plugin" or "middleware" and start treating it as a cryptographic primitive. By moving to a stateless, mathematically verifiable model, we reduce infrastructure complexity (no Redis dependency) while increasing the granularity of our security assertions.

Sigil is currently in the implementation phase, designed to be the boring, reliable cryptographic bedrock for request intent verification.

---

For a more detailed examination, here is the GitHub repository.

→ https://github.com/laphilosophia/sigil-security

---

Suggested Next Steps for the reader:

Check the SPECIFICATION.md in the repository for the full architectural breakdown of the HKDF implementation.