1---
2title: Prevent Cross-Request State Pollution in SSR Applications
3impact: CRITICAL
4impactDescription: Singleton stores in SSR share state across all server requests, potentially leaking user data between requests
5type: gotcha
6tags: [vue3, ssr, state-management, pinia, vuex, security, server-side-rendering, nuxt]
7---
8 
9# Prevent Cross-Request State Pollution in SSR Applications
10 
11**Impact: CRITICAL** - In Server-Side Rendering (SSR) applications, a singleton store pattern creates a single instance that is shared across all server requests. This means data from one user's request could leak into another user's response, causing serious security and data integrity issues.
12 
13This is one of the most critical gotchas in Vue state management that can have severe production consequences.
14 
15## Task Checklist
16 
17- [ ] Never use a singleton store pattern in SSR applications
18- [ ] Create a fresh store instance per request when using SSR
19- [ ] Use Pinia which handles SSR state management correctly
20- [ ] Test SSR state isolation with concurrent requests
21- [ ] Review any global reactive state for SSR compatibility
22 
23## The Problem: Singleton State in SSR
24 
25```javascript
26// store.js - DANGEROUS for SSR
27import { reactive } from 'vue'
28 
29// This is a singleton - same instance for ALL requests
30export const store = reactive({
31  user: null,
32  cart: [],
33  preferences: {}
34})
35```
36 
37**What happens in SSR:**
38 
391. Request A comes in for User A
402. Server sets `store.user = userA`
413. Before response completes, Request B arrives for User B
424. Request B sees `store.user = userA` (User A's data leaked!)
435. Server sets `store.user = userB`
446. Request A's response might now contain User B's data
45 
46This creates unpredictable behavior and potential security vulnerabilities.
47 
48## Solution 1: Use Pinia (Recommended)
49 
50Pinia handles SSR correctly by creating fresh store instances per request:
51 
52```javascript
53// stores/user.js
54import { defineStore } from 'pinia'
55 
56export const useUserStore = defineStore('user', {
57  state: () => ({
58    user: null,
59    preferences: {}
60  }),
61  actions: {
62    setUser(user) {
63      this.user = user
64    }
65  }
66})
67```
68 
69```javascript
70// main.js (or entry-server.js)
71import { createPinia } from 'pinia'
72import { createApp } from 'vue'
73import App from './App.vue'
74 
75// For SSR: Create fresh instances per request
76export function createAppInstance() {
77  const app = createApp(App)
78  const pinia = createPinia()
79 
80  app.use(pinia)
81 
82  return { app, pinia }
83}
84```
85 
86```javascript
87// entry-server.js
88import { createAppInstance } from './main'
89import { renderToString } from 'vue/server-renderer'
90 
91export async function render(url, context) {
92  // Fresh app and store instance per request
93  const { app, pinia } = createAppInstance()
94 
95  // ... setup router, fetch data, etc.
96 
97  const html = await renderToString(app)
98 
99  // Serialize state for client hydration
100  const state = pinia.state.value
101 
102  return { html, state }
103}
104```
105 
106```javascript
107// entry-client.js - Hydrate from serialized state
108import { createAppInstance } from './main'
109 
110const { app, pinia } = createAppInstance()
111 
112// Restore server state before mounting
113if (window.__PINIA_STATE__) {
114  pinia.state.value = window.__PINIA_STATE__
115}
116 
117app.mount('#app')
118```
119 
120## Solution 2: Factory Pattern for Hand-Rolled State
121 
122If not using Pinia, create a factory function:
123 
124```javascript
125// store.js - SSR-safe with factory
126import { reactive, readonly } from 'vue'
127 
128// Factory function creates fresh state per call
129export function createStore() {
130  const state = reactive({
131    user: null,
132    cart: [],
133    preferences: {}
134  })
135 
136  return {
137    state: readonly(state),
138    setUser(user) {
139      state.user = user
140    },
141    addToCart(item) {
142      state.cart.push(item)
143    }
144  }
145}
146```
147 
148```javascript
149// entry-server.js
150import { createStore } from './store'
151import { provide } from 'vue'
152 
153export async function render(url) {
154  const app = createApp(App)
155 
156  // Fresh store instance for this request only
157  const store = createStore()
158  app.provide('store', store)
159 
160  // ... render
161}
162```
163 
164## Solution 3: Context-Based State (Advanced)
165 
166For frameworks like Nuxt, use request context:
167 
168```javascript
169// composables/useRequestState.js
170import { useSSRContext } from 'vue'
171 
172export function useRequestState(key, initialValue) {
173  if (import.meta.env.SSR) {
174    const ctx = useSSRContext()
175    ctx.state = ctx.state || {}
176 
177    if (!(key in ctx.state)) {
178      ctx.state[key] = initialValue()
179    }
180 
181    return ctx.state[key]
182  }
183 
184  // Client-side: use regular reactive state
185  return reactive(initialValue())
186}
187```
188 
189## Nuxt.js Handles This Automatically
190 
191In Nuxt 3, state isolation is handled automatically:
192 
193```javascript
194// Nuxt automatically creates fresh Pinia instance per request
195// You can use stores normally
196 
197export default defineNuxtPlugin(async (nuxtApp) => {
198  const userStore = useUserStore()
199  await userStore.fetchUser()
200})
201```
202 
203## Testing for State Pollution
204 
205```javascript
206// test/ssr-state-isolation.test.js
207import { describe, it, expect } from 'vitest'
208import { render } from './entry-server'
209 
210describe('SSR State Isolation', () => {
211  it('should not leak state between concurrent requests', async () => {
212    // Simulate concurrent requests
213    const [result1, result2] = await Promise.all([
214      render('/user/1', { userId: '1' }),
215      render('/user/2', { userId: '2' })
216    ])
217 
218    // Each should have their own user data
219    expect(result1.html).toContain('User 1')
220    expect(result2.html).toContain('User 2')
221 
222    // State should not be mixed
223    expect(result1.html).not.toContain('User 2')
224    expect(result2.html).not.toContain('User 1')
225  })
226})
227```
228 
229```javascript
230// Alternative: Test store isolation directly
231import { createApp } from './app.js'
232 
233test('requests do not share state', async () => {
234  // Simulate two concurrent requests
235  const { app: app1, store: store1 } = createApp()
236  const { app: app2, store: store2 } = createApp()
237 
238  store1.user = { id: 1, name: 'Alice' }
239  store2.user = { id: 2, name: 'Bob' }
240 
241  // Each should have its own state
242  expect(store1.user.name).toBe('Alice')
243  expect(store2.user.name).toBe('Bob')
244})
245```
246 
247## Red Flags to Watch For
248 
249```javascript
250// ANY module-level reactive state is dangerous in SSR
251 
252// BAD: Module-level reactive
253export const globalUser = ref(null)
254 
255// BAD: Module-level reactive object
256export const appState = reactive({})
257 
258// BAD: Shared Map/Set
259export const cache = new Map()
260 
261// BAD: Even plain objects can be problematic
262let requestCount = 0  // Shared across requests
263```
264 
265## Why Pinia is Recommended for SSR
266 
2671. **Automatic request isolation** - Fresh store instances per request
2682. **Built-in state serialization** - Easy hydration on client
2693. **DevTools support** - Debug state on both server and client
2704. **TypeScript support** - Type-safe state management
2715. **Tested patterns** - Battle-tested SSR handling
272 
273## Reference
274- [Vue.js State Management - SSR Considerations](https://vuejs.org/guide/scaling-up/state-management.html#ssr-considerations)
275- [Pinia SSR Guide](https://pinia.vuejs.org/ssr/)
276- [Vue SSR Guide](https://vuejs.org/guide/scaling-up/ssr.html)
277