Svelte 5 Runes Universal Store Cross-Request State Leakage Prevention

--- description: Svelte 5 Runes Universal Store Cross-Request State Leakage Prevention - Enforces strict per-request isolation for Svelte 5 reactive runes ($state) in universal and server-side rendering (SSR) environments. In persistent runtime worker environments (Node.js, Bun, Cloudflare Workers), module-level reactive singletons bleed authenticated sessions, PII, and request mutations across concurrent user requests. Engineers must encapsulate mutable state within component contexts or per-request lifecycle factories. globs: src/**/*.{svelte,svelte.ts,ts,js} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/svelte-5-runes-ssr-universal-store-leak-prevention" --- # Svelte 5 Runes Universal Store Cross-Request State Leakage Prevention > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Module-Scoped $state() Singletons Leaking Concurrent User Sessions During SSR ## System Constraints You are a Principal Software Architect enforcing deterministic SSR state isolation in Svelte 5 applications. Svelte 5 introduces universal runes ($state, $derived) operable in non-component *.svelte.ts modules. You must strictly prevent module-level instantiation of mutable reactive runes that persist in global module scope across Node.js/V8 isolates during SSR. Enforce per-request lifecycle encapsulation using Svelte Context APIs (setContext, getContext) or per-request factory instantiation bound to SvelteKit event locals. ## Strict Guidelines - Engineers MUST NOT declare mutable `$state` or `$state.raw` singletons at the root module scope of universal `.svelte.ts` files that execute during SSR. - Engineers MUST encapsulate shared reactive state within a factory function or class instantiated per-request and injected via `setContext` inside root layouts or server-initiated boundaries. - Services MUST retrieve reactive session, auth, or transactional state via `getContext` inside the component tree or accept state explicitly as functional parameters. - Engineers MUST use `event.locals` in SvelteKit hooks (`hooks.server.ts`) for server-side persistence, passing initial snapshots via data loaders (`+layout.server.ts` or `+page.server.ts`) instead of populating global stores. - Components NEVER reassign or mutate module-level exported variables directly in SSR contexts, preventing node process worker cycle contamination across disparate tenant sessions. - Code SHOULD enforce strict type-safe Context keys using `Symbol()` to prevent collision and verify context existence with defensive assertion wrappers. ## Bad vs Good Implementations ### Cross-Request Session Bleed via Module-Level Rune Singleton #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: During SSR, Node.js or Bun processes do not clear ES module state between incoming HTTP requests. The `userSession` singleton is shared across all concurrent threads and worker cycles. If Request A populates `userSession` with Tenant A's private bearer token, Request B executing in the same worker isolate reads Tenant A's cached state before or during render, leading to critical cross-tenant data exposure. ```typescript // src/lib/stores/user-session.svelte.ts // ANTI-PATTERN: Root-level $state in universal module persists in Node runtime process! interface UserSession { userId: string | null; isAuthenticated: boolean; token: string | null; } // Leaks between concurrent SSR requests on long-lived worker processes export const userSession = $state<UserSession>({ userId: null, isAuthenticated: false, token: null }); export function setUserSession(data: UserSession): void { userSession.userId = data.userId; userSession.isAuthenticated = data.isAuthenticated; userSession.token = data.token; } ``` #### Production Standard (Correct) > **Standard**: The store class is created per-request inside the Svelte component tree using `setUserSessionContext` (typically in `+layout.svelte` fed by `data.session` from `+layout.server.ts`). Svelte's Context API is bound to the active component tree instance, which is strictly ephemeral and discarded after HTML serialization, guaranteeing zero session bleeding across concurrent worker cycles. ```typescript // src/lib/stores/user-session.svelte.ts import { getContext, setContext } from 'svelte'; export interface UserSession { userId: string | null; isAuthenticated: boolean; token: string | null; } export class UserSessionStore { #state = $state<UserSession>({ userId: null, isAuthenticated: false, token: null }); constructor(initialData: UserSession) { this.#state = $state({ ...initialData }); } get current(): UserSession { return this.#state; } update(data: Partial<UserSession>): void { Object.assign(this.#state, data); } } const SESSION_KEY = Symbol('USER_SESSION_CONTEXT'); export function setUserSessionContext(initial: UserSession): UserSessionStore { const store = new UserSessionStore(initial); setContext(SESSION_KEY, store); return store; } export function getUserSessionContext(): UserSessionStore { const store = getContext<UserSessionStore>(SESSION_KEY); if (!store) { throw new Error('UserSessionContext must be initialized in component root via setContext'); } return store; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Runes Universal Store Cross-Request State Leakage Prevention

Svelte 5 Runes Universal Store Cross-Request State Leakage Prevention defines an industrial-grade behavioral standard for frontend engineering. Enforces strict per-request isolation for Svelte 5 reactive runes ($state) in universal and server-side rendering (SSR) environments. In persistent runtime worker environments (Node.js, Bun, Cloudflare Workers), module-level reactive singletons bleed authenticated sessions, PII, and request mutations across concurrent user requests. Engineers must encapsulate mutable state within component contexts or per-request lifecycle factories. 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: Module-Scoped $state() Singletons Leaking Concurrent User Sessions During SSR 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	Module-Scoped $state() Singletons Leaking Concurrent User Sessions During SSR	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 NOT declare mutable `$state` or `$state.raw` singletons at the root module scope of universal `.svelte.ts` files that execute during SSR.

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.