server no shared module state
For React Server Components and client components rendered during SSR, avoid using mutable module-level variables to share request-scoped data. Server renders can run concurrently in the same process. If one render writes to shared module state and another render reads it, you can get race conditions, cross-request contamination, and security bugs where one user's data appears in another user's re
Overview
Avoid Shared Module State for Request Data
For React Server Components and client components rendered during SSR, avoid using mutable module-level variables to share request-scoped data. Server renders can run concurrently in the same process. If one render writes to shared module state and another render reads it, you can get race conditions, cross-request contamination, and security bugs where one user's data appears in another user's response.
Treat module scope on the server as process-wide shared memory, not request-local state.
Incorrect (request data leaks across concurrent renders):
let currentUser: User | null = null
currentUser = await auth()
return
}
async function Dashboard() {
return <div>{currentUser?.name}</div>
}
If two requests overlap, request A can set currentUser, then request B overwrites it before request A finishes rendering Dashboard.
Correct (keep request data local to the render tree):
const user = await auth()
return
}
function Dashboard({ user }: { user: User | null }) {
return <div>{user?.name}</div>
}
Safe exceptions:
- Immutable static assets or config loaded once at module scope
- Shared caches intentionally designed for cross-request reuse and keyed correctly
- Process-wide singletons that do not store request- or user-specific mutable data
For static assets and config, see Hoist Static I/O to Module Level.