Sharing a global variable across multiple requests is unsafe in SSR

[sjmueller]

Describe the bug

In adopting Svelte for our chat+communities app, we are trying to utilize the Store for our complex state needs. In this process, we came across semantic differences between stores on the client vs the server that are very concerning -- described in detail here: #2213 Using a Svelte store in the load function causes weird behavior

as soon as you create your own store, it becomes global server-side in a SSR context (= your store is a singleton in memory server-side, so it is shared by all HTTP requests hitting your server)

We are coming from react+redux, which also has the concept of a store where you would keep complex global state. In our app, we use it to store the authenticated user's profile and private conversations+messages. If we did this in a Svelte Store where it's treated as an in-memory singleton, there's the significant potential to leak personal/sensitive data to others using the app. Furthermore, SvelteKit documentation does a good job of making the case that Stores are where complex state should happen, but makes no mention of the implicit risks and impedance mismatch when SSR is used in conjunction with Stores.

What is the recommended approach for handling complex, user-specific (private) global reactive state in SvelteKit? Are there any plans to address the implications of SSR Stores more explicitly in the documentation?

Reproduction

See #2213 for reproduction

Logs

No response

System Info

`@sveltejs/kit 1.0.0-next.282`

Severity

serious, but I can work around it

Additional Information

No response

[sjmueller]

@babichjacob it's inconsiderate to close and lock an issue without any explanation

we're trying to contribute+become part of the svelte community -- so getting auto-silenced feels like an invalidating and unwelcoming start

[dummdidumm]

You are right that an explanation is missing, and I'm sorry about that. I guess it was moved to a discussion because this is a usage question ticket, not a bug/feature request ticket. The loading docs and state management docs also make it clear (IMO) that you should not use global variables (so, also stores if they are global), so it's not a documentation issue either (maybe in this discussion it turns out it is, we can always revisit this), so this was moved to a discussion.

[babichjacob]

The issue wasn't closed, it was converted to a discussion.

Further, it is a duplicate of an existing closed issue (which was also closed for being a usage question #2213 (comment)) and is a usage question rather than a bug report.

What is the recommended approach for handling complex, user-specific (private) global reactive state in SvelteKit?

The only reason I converted it to a discussion without an explicit explanation is because there is one provided by GitHub as shown, and I was confident that for the aforementioned reasons it was the right thing to do to help other maintainers with the issue tracker and because talking about the problem wasn't inhibited by doing this.

[sjmueller]

the issue was literally closed and locked, a subject we spent time discussing, researching and socializing before deciding to open -- if not a bug, it is a serious artifact in SK SSR that could yield detrimental outcomes -- still not sure why the consensus is that it doesn't deserve to be an issue, but we'll see how opinions develop in this discussion

that being said, i do appreciate you providing context around your process and reasoning, it's helpful

[AlbertMarashi]

I've proposed a solution to this problem here #9878

[dummdidumm]

You could wrap store usage using Svelte's context API. That way they are scoped to a component and its children, therefore scoped per user:

// store.js
import { setContext, getContext } from 'svelte';

export function createMyCustomStore() {
  setContext('someUniqueName', writable('some content'));
}

export function getMyCustomStore() {
  getContext('someUniqueName');
}

// src/routes/__layout.svelte
<script>
  ...
  createMyCustomStore();
</script>

// src/routes/somewhereelse.svelte
<script>
  const store = getMyCustomStore();
  ...
</script>

Note that this means that you need to call these get/set methods on component initialization.

[sjmueller]

after trying many things with @tedmeftah, we landed on stuffing in the context just like your suggestion

fingers crossed in the future we get a more semantically consistent manner of populating stores on SSR that doesn't sneakily behave differently compared to client side (i.e. avoid global shared state)

[rohanrajpal]

Hey, @dummdidumm is this still the recommended or would you recommend something better now? (with all the recent changes implmented in svelte kit)

[joaquimnetocel]

I believe that a return is missing in your "getMyCustomStore".

Here is what worked for me:

// store.ts
import { getContext, setContext } from 'svelte';
import { writable, type Writable } from 'svelte/store';

export function createStore() {
	const mystore = writable('INITIAL VALUE');
	setContext('contextStore', mystore);
}

export function readStore() {
	return getContext<Writable<string>>('contextStore');
}

<!-- +layout.svelte -->
<script lang="ts">
	import { createStore } from './store';
	createStore();
</script>

<slot />

<!-- IN ANY COMPONENT: -->
<script lang="ts">
	import { readStore } from './store';
	const storeData = readStore();
	$storeData = 'NOW YOU CAN CHANGE THE STORE WITHOUT SHARING THE VALUE WITH OTHER USERS.';
</script>

{$storeData}

[jerriclynsjohn]

This should be in the docs!

[diamondalltheway]

@dummdidumm thanks for the recommendation!

[sjmueller]

Thanks for taking the time and chiming in @dummdidumm

The loading docs also make it clear (IMO) that you should not use global variables (so, also stores if they are global), so it's not a documentation issue either

We believe the docs are neither clear nor explicit, for these reasons:

• The loading docs warning: Mutating any shared state on the server will affect all clients, not just the current one. is ambiguous about stores -- there isn't a direct correlation that stores are shared global state
• Unless I've missed it, the store docs don't mention anywhere how stores become global server-side singletons in an SSR context. This is important because anyone coming from redux (or any other SPA store concept) will see svelte stores as nearly identical in semantics, except for this huge and dangerous difference

At this point, we still feel that svelte stores should house our global state (just like a redux store), and to achieve the desired result on SSR we're using stuff to transport data from load within the module context so that we can safely initialize the store with the user's personal data. Honestly feels a bit hacky, and we still have great concern that a dev will accidentally init the store with private data directly within load, which potentially triggers a data leak:

// src/routes/__layout.svelte
<script context="module">
  export async function load({ fetch }) {
    const res = await fetch("api.blink.xyz/conversations")
    const conversations = await res.json()
    return {
      stuff: { conversations }
    }
  }
</script>

<script>
  import conversationStore from "$lib/stores/conversations"
  import { page } from "$app/stores"
  conversationStore.update($page.stuff.data)
</script>

// src/routes/somewhereelse.svelte
<script>
  import conversationStore from "$lib/stores/conversations"
</script>

<ul>
  {#each $conversationStore[1].messages as message}
    <li>{message.sender}: {message.content}</li>
  {/each}
</ul>

[sjmueller]

What do you think about the way we are populating our store with personal data using stuff as a transport? Is there a better way?

Also, would it make sense for SK to introduce a different context in which load could be used? Example:

<script context="request"> // instead of [global] "module"?
  export async function load({ fetch }) { ... }
</script>

[benmccann]

Your load function is fine (assuming there's no bug on the SvelteKit side 😄) and the suggestion you make would not help at all. The issue would be in import conversationStore from "$lib/stores/conversations". That looks likely to be a global variable. To address it, you could do as @dummdidumm suggested above: #4339 (comment)

[itssumitrai]

Hi @benmccann ,
Thanks for your reply. Could you provide me a suggestion regarding my query as well ?
I like to keep my data fetching separate from my page Component.

// index.svelte
<script context="module">
import fetchData from '$lib/actions/fetchData.js';
 export async function load(context) {
     await fetchData(context, { foo: 'bar' });
 }
</script>

The reason for doing this is:

1. Cleaner code especially when you have tons of async actions running
2. We can reuse the same action across multiple pages

Now if we want to do the above suggested stores into context. How do we access that store inside the action file ?

I get this error: Error: Function called outside component initialization when I try to use
getContext('__stores__') inside fetchData.js.
Its fine in any component though. Any suggestions on how to handle this ?
Thanks.

[pevey]

<script context="module"> export async function load({ fetch }) { const res = await fetch("api.blink.xyz/conversations") const conversations = await res.json() return { stuff: { conversations } } } </script>

It's been a couple of weeks now, but I just want to point out that the above code will not necessarily always run on the server, which seems like your intent. Here is the relevant snippet from the docs:

load is similar to getStaticProps or getServerSideProps in Next.js, except that load runs on both the server and the client. In the example above, if a user clicks on a link to this page the data will be fetched from cms.

Perhaps I misunderstand, and running server or client side, depending on the situation, would be fine for your use case. But it not, I think the better solution would be to use the context example provided by @dummdidumm.

[sjmueller]

we definitely want load to run on the server or client, depending on the circumstance

i think it all comes down to having a store-per-request, even on SSR -- and right now it seems like stuffing them into the context (like @dummdidumm suggests above) is the only way, even though it seems like a hack

[itssumitrai]

I was just about to create a post for this same issue. Since Svelte stores are generally written as files where you have to initialize it like writable(), it becomes global for all the server requests.
The only way to do this safely on server seems to be what @dummdidumm suggested above by putting the store into the context, and thats exactly what SvelteKit also does for page & other stores.
But we don't have the access to the root component, so we can't set a store into the context which would be available everywhere through the app :(
It would be great if Sveltekit could provide a way to add stores to the __svelte__ context where other stores live, that way the stores could be used easily and safely even in SSR

[hyunbinseo]

Since Svelte stores are generally written as files where you have to initialize it like writable(), it becomes global for all the server requests.

An example would be the official Stores / Writable stores • Svelte Tutorial.

// stores.js

import { writable } from 'svelte/store';

export const count = writable(0);

<!-- Incrementer.svelte -->

<script>
  import { count } from './stores.js';

  function increment() {
    // Problematic in SSR environments
    count.update((n) => n + 1);
  }
</script>

<button on:click={increment}> + </button>

[lukaszpolowczyk]

For security and clarity, all tutorials and examples (including those for pure SvelteJS, without SvelteKit) should be updated to be ready for use with SvelteKit with SSR as well.
What do you think?

[itssumitrai]

Since there hasn't been any new activity on this thread, I have been experimenting on this a little bit, and I have found that using stuff works pretty well for me. stuff is available in any load function & its specific to a given request, plus it could also be accessed using $page.stuff in any component.

So, my solution is basically not have global stores. My Store file looks like:

fooStore.js

import { writable } from 'svelte/store';
export default function () {
   return writable(0);
}

Notice that we return a function which instantiates the store. This is important to ensure we are not using global stores around on server.

Now in __layout.svelte

import fooStore from '$stores/fooStore.js';
export async function load() {
     const storeInstances = {
         foo: fooStore() 
     };
     return {
         stuff: {
            ...storeInstances
         }
     }
}

Now you can use your fooStore instance without any worry from the stuff
either as stuff.foo in load function or $page.stuff.$foo in your components.

One caveat: Sveltekit removes stuff even on the client side navigations which I find very weird to do, so that means if you want to persist stores between client side navigations, you would have to add the additional logic yourself, same would be true with getContext as well.

[itssumitrai]

@sjmueller See if that works for you

[sjmueller]

Sveltekit removes stuff even on the client side navigations ... same would be true with getContext as well

Thanks for chiming in @itssumitrai, we didn't actually realize how svelte handles stuff and context when it comes to client side navigation.

Ideally we'd have non-global stores on SSR that get populated for the duration of the request, and then those same stores stick around on the client and persist through all client side navigation. Would be great if the core team could share their thoughts and recommended approach on this issue cc @Rich-Harris

[AlbertMarashi]

Ok but it's just a bit annoying having to do this everywhere across my code $page.stuff.alerts...

[itssumitrai]

I agree, I just created a util method for this getStore(storeName). I haven't really found any good alternative solutions for this problem.

[AlbertMarashi]

I kinda agree with this, there should be a JS sandbox being created per request. I understand the overhead, but i think it's critical for security, many devs are probably unaware of this caveat, despite a small note about it in the docs

[Kraftwurm]

many devs are probably unaware of this caveat

You are so right. I'm very glad to have stumbled upon this conversation!

[AlbertMarashi]

@dummdidumm @Rich-Harris I have experience playing around with Vue's sandboxing system that they use to isolate module state from eachother using node's vm features. I would be happy to collaborate with someone, with the goal of creating a sveltekit adapter to achieve this.

Using stores like normal javascript I find is generally the most convenient and not needing to worry about potential security vunerabilities between shared user state is a big plus.

Edit: Please see the following proposal

• Proposal for Svelte 5: Universal Reactivity & Safe SSR Global State? svelte#12947

[sjmueller]

thanks for pushing this forward @AlbertMarashi

[giray123]

Eventually we have also come accross this problem. This seems like one of hte biggest issues of Sveltekit. All solutions proposed seems not cool considering the ease-of-use of Sveltekit. What is the disadvantage of restricting the stores on the request context?

Additionally, currently tried the below approach (upon populating store on SSR). We get an empty store on SSR. But this also does not help because since it gives an empty store on each server import, it is meaningless.

export const hello = writable<string | null>(null)

export function getHelloStore() {
	if (!browser) {
		return writable<string | null>(null)
	} else {
		return hello
	}
}

In the end I am really really confused, as far as I understand either you set a store on script or a script context it changes the shared store on server. This is a very dangerous thing and all the examples in the docs are susceptible to this. Please correct me if I am wrong. The docs are directly directing to a security vulnerability. (yes, there is a sentence about this but I am referencing almost all the store code examples.)

@Rich-Harris, what is really interesting is that there have been 2 issues about this problem, 1 is closed and the other (this one) is converted into a discussion. For me and my team this is the number 1 issue currently in Sveltekit. Can somebody from Sveltekit please explain what is the ultimate correct way to use the stores considering the SSR and security?

[CaptainCodeman]

I'm not 100% sure, but I think this is the same issue that I came across (or at least very similar) where I wanted to have a store, using server-rendered data, but then upgrade that store to become client-side once hydrated - in my case because I'm them subscribing to Firestore on the client (but want the initial fast load). In addition, I don't want to load data from the server on each navigation once the client is hydrated.

I figured out a way to do it but it's not obvious. Hopefully this is enough of a gist to explain the approach ...

First, maintain a flag to know if hydration has happened:

import { browser } from '$app/env'

// In order to prevent the browser doing both a fetch of data from and endpoint
// and a subscription to Firestore, we keep a flag to indicate if we're doing
// the initial load on the client or not (based on whether hydration has run).
// Note that even though we do the fetch on the client for the first execution
// we don't actually go across the network because of how SvelteKit embeds the
// JSON payload into the page, so it acts as a way of getting that initial SSR
// content to seed the store with, while the Firestore subscription is loading.

let _hydrated = false

if (browser) {
  window.addEventListener('sveltekit:start', () => _hydrated = true, { once: true })
}

// returns true if the code is running in the browser and hydration has completed
export const hasHydrated = () => _hydrated

Have two store implementations, one very simple to just contain the data:

export const contentsFactory = (contents: any[]) => writable(contents)

And one richer to do the client-side pieces (in this case, the firestore subscription):

export function clientContentsFactory(site, contents) {
  const { subscribe } = writable(contents, set => {
    const q = query(collection(firestore, 'blog', site, 'content'), limit(5))
    const unsub = onSnapshot(q, r => {
      const contents = r.docs.map(doc => toJS(doc))
      set(contents)
    })
    return unsub
  })

  return { subscribe }
}

The load function uses the hydration flag to determine which store to use and also to do the server-side fetch if required. The loaded data is used to seed the store on both server and client, which prevents any flash of SSR'd data before the client-subscribed data then replaces it.

<script lang="ts" context="module">
  import type { Load } from '@sveltejs/kit'
  import { contentsFactory } from '$lib/stores';
  import { browser } from '$app/env';
  import { clientContentsFactory } from '$lib/firebase-client';
  import type { Readable } from 'svelte/store';
  import { hasHydrated } from '$lib/hydrated';

  export const load: Load = async ({ fetch, params }) => {
    async function fetchData() {
      const resp = await fetch('/api/contents?blog=' + params.site)
      const data = await resp.json()
      return data
    }

    const data = hasHydrated() 
      ? []
      : await fetchData()

    const contents = browser
      ? clientContentsFactory(params.site, data)
      : contentsFactory(data)

    return {
      props: { contents },
    }
  }
</script>

<script lang="ts">
  export let contents: Readable<any[]>
</script>

<h5>Contents</h5>

<ul>
{#each $contents as content}
  <li>{content.id}</li>
{/each}
</ul>

As I said, it's non-obvious and it's easier to understand if you step through it in the debugger. There are really 3 paths through the load function: SSR, SSR being re-hydrated on client, client-side navigation.

Apologies if it's not really relevant, but even so it may give you some ideas.

[giray123]

I kind of understand what you did there. Thanks for sharing. Again, this feels like a lot of hacky code to make a simple thing to work. And if you set a store variable in your script anywhere as in the examples, again it will be a problem on SRR. The main advantage of stores in the end is that we import them inside multiple components to do some stuff in the script tag. The only correct way, as I see, is to make the stores request-specific at the server. I feel that it should not be a huge thing to implement but probably I am missing something that the devs would explain.

[raduab]

We ran into the same issue with our app. Data was leaking between requests, and we also used server-side authentication, so this posed a significant security risk. I ended up writing a custom store that could be used in the same way as Svelte's default writable store, using the context as previously suggested. This custom store is sandboxed on the server, and it becomes a Svelte writable store on the client:

// sandboxedStore.js
//

import { browser } from '$app/environment'
import { getStores } from '$app/stores'
import { v4 as uuidv4 } from 'uuid'
import { get, writable as svelteWritable } from 'svelte/store'

const storesKey = `sandbox_${uuidv4()}`

/**
 * Creates a façade for a writable store that is a sandboxed store that may be used as a
 * global variable. It must be initialized during component initialization.
 *
 * This store is contextual since it is added to the context of the root component. This means that
 * it is unique to each request on the server rather than shared across multiple requests handled
 * by the same server at the same time, allowing it to be used as a global variable while also
 * holding user-specific data.
 *
 * We must subscribe to this store during component initialization before we can use it. It is
 * utilized in the same way as [SvletKit's app stores](https://kit.svelte.dev/docs/modules#$app-stores).
 *
 * _NB: In async methods, set the store before any await, otherwise, the context will be lost once
 * the promise is fulfilled._
 *
 * @param {any} initialValue An initial value to set the store to
 * @param {string} [key] An optional key name for the store
 */
export function writable(initialValue, key) {
  key = key ? `${key}_${uuidv4()}` : uuidv4()

  function setStore(value) {
    try {
      const { page: sessionStore } = getStores()
      const session = get(sessionStore)

      const store = session?.[storesKey]?.[key]
      const currentValue = store ? store.value : initialValue

      if (!store || value !== currentValue) {
        if (!session[storesKey]) session[storesKey] = {}
        session[storesKey][key] = {
          value,
          subscribers: store?.subscribers || [],
        }

        // alert subscribers
        if (store) {
          store.subscribers.forEach(fn => {
            fn(value)
          })

          // return the updated value
          return value
        }
      }
    } catch (error) {
      // if we reached this exception, it meant that the store had not yet been initialized
      return value
    }
  }

  const sandboxedWritable = {
    set: setStore,

    subscribe: fn => {
      try {
        const { page: sessionStore } = getStores()
        const session = get(sessionStore)

        const store = session?.[storesKey]?.[key]
        const currentValue = store ? store.value : initialValue

        // call the subscription function with the current value
        fn(currentValue)

        // register the subscriber
        if (!session[storesKey]) session[storesKey] = {}
        session[storesKey][key] = {
          value: store?.value || initialValue,
          subscribers: [...(store?.subscribers || []), fn],
        }
      } catch (error) {
        // if we reached this exception, it meant that the store had not yet been initialized
        // call the subscription function with the initial value
        fn(initialValue)
      }

      // return the unsubscribe function
      return function unsubscribe() {
        try {
          const { page: sessionStore } = getStores()
          const session = get(sessionStore)

          // unregister the subscriber
          const { subscribers } = session[storesKey][key]
          subscribers.splice(subscribers.indexOf(fn), 1)
        } catch (error) {
          // if we reached this exception, it meant that the store had not yet been initialized
          // ignore
        }
      }
    },

    update: fn => {
      try {
        const { page: sessionStore } = getStores()
        const session = get(sessionStore)

        const store = session?.[storesKey]?.[key]
        const currentValue = store ? store?.value : initialValue

        setStore(fn(currentValue))
      } catch (error) {
        // if we reached this exception, it meant that the store had not yet been initialized
        setStore(fn(initialValue))
      }
    },
  }

  return browser ? svelteWritable(initialValue) : sandboxedWritable
}

EDIT: I updated the code, to remove stuff that was no longer available in the page store, e.g.:

  const { page: sessionStore } = getStores()
- const { stuff: session } = get(sessionStore)
+ const session = get(sessionStore)

You can use this writable store in the same way as the default one, with the exception that it will not leak data on the server between requests. You can also specify a value to initialize the store with, which will be set only after the context is available:

import { writable } from 'sandboxedStore'

const foo = writable()
const bar = writable('initial value')

[Bewinxed]

I don't know why a lot of people are surprised about user-specific stores, I think the majority of usecases would like stores to be user specific and not global.

why can't we just writable(value:any, global:boolean)?

This solution helped a lot!

[raythurnvoid]

How is this better than using context? #4339 (comment)

[wiwa]

I was able to get this to work in Typescript by using const session = get(sessionStore).data (added the .data). Honestly, not sure how we can just mutate the App.PageData like that.
For now, I'm using get(sessionStore).data.stores, and then in my routes/+layout.ts:

import type { LayoutLoad } from "./$types";

export const load = (async () => {
  return {
    stores: {}
  };
}) satisfies LayoutLoad;

I'm also not sure why we need the const storesKey = sandbox_${uuidv4()}` -- I'm assuming this is so the key doesn't conflict with any key we might use in our application.

[wiwa]

@raythurnevoid this is better than using context api because:

1. It is a drop-in replacement for Svelte stores instead of requiring significant boilerplate code.
   a. Don't need to cast to get the right types.
2. You don't need to be careful about referencing the store during component initialization.

[sulitprod]

Who tried to call the store inside +layout.svelte, but set the value in +page.svelte?
I have this structure:

(profile)
- profile
-- +page.svelte
- [@id]
-- +page.svelte
- +layout.svelte

The page of your profile and someone else's are identical except for a couple of UI elements and additional pages, which means that you need to pass basic information to the layout, but I encountered the fact that the store is empty on the first render, so the profile flickers on the first load.

[aradalvand]

I absolutely agree that this behavior is non-obvious and as such should be mentioned and explained much more clearly in the docs.

Declaring a store in a separate file and then importing it in components and so on is how you do global stores in vanilla Svelte, and so many people are probably assuming they can do the same thing in SvelteKit, while not actually realizing that it could be problematic.

[alucav]

i am thankful that i stumbled across this post. these issues were feeling insurmountable. @raduab thank you so much for taking the time to share what your elegant solution. with the recent updates, it seems to not be fully working. i have to make it work on a project so if I am able to I will post the modified version here.

glad to be part of such a great community.

update: this is actually working just fine with the current version ("@sveltejs/kit": "^1.0.0-next.443"). The issue was in my implementation.

[kvetoslavnovak]

I would really prefer in build solution for the store in SSR with sensitive user data. Maybe leaving session store behind (removal of the session store) was too hasty.

For the use cases discussed here the old session was really great and easy to use tool/. Even tools like Supabase SvelteKit Auth Helpers were build upon and embraced this feature.

[aradalvand]

Yes, the removal of the session was an absolutely horrid decision and I'll die on this hill.

[nickyhajal]

I have been hitting this issue as I mentioned here #8614 (comment).

Is @raduab's solution above still what most people here are using? Has any progress been made else where that I'm missing?

Thanks!

[raduab]

This is still used in production after being updated to reflect the most current SvelteKit changes (see above)

[wiwa]

Hi! Thanks for bringing up this info. Imo, this is quite unexpected behavior, and if a developer of an API needs people to read very carefully, then their users are not going to read (hi, user here).

(All in my newbie opinion:)

In Svelte (i.e. just client-side), stores don't have cross-session behavior (i.e. User1 will never see User2's info).
It doesn't make much sense that SvelteKit would add this behavior, and only when using SSR (not even purposefully changing the store on the server). An app rendered client-side which can be rendered server-side should not change its behavior just because SSR was turned on. (As a newb to frontend) I expect SSR to "simply" be a performance enhancement, assuming the semantics of my web app allow it to be switched on. In this paradigm, SSR should not change the sandboxed nature of client-only stores.

Otherwise, I would personally just turn off SSR if I'm using stores, unless I were using a workaround like those in this discussion.

[cedricr]

Otherwise, I would personally just turn off SSR if I'm using stores

Unfortunately, turning off SSR with SvelteKit, and contrarily to what the documentation says, you're loosing all SEO, not some of it. From the experiments I've done, Google was unable/unwilling to fetch more than a few of the dozens of javascript files necessary to render a page, and I wasn't able to find how to have SK generate a unique js bundle either…

[t-heuser]

We were having the exact same issues and started to use prerender.io, but that brings in lots of more problems and is just a workaround as Google says itself (https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering).

So we rebuild our application with SSR and now facing the problems described in this thread with shared global stores on the server side which is a huge bummer.

[aloker]

To be honest, I don't think this requires a technical solution. Sticking to good programming practices is sufficient. Devs should just avoid using globals. Really, this has been taught for decades, long before web dev was a thing.

If you need per-request stores, put them in context and/or locals and pass them explicitly to the functions that require them. A pure function that does not reply on implicit global state is much less trouble.

I know putting stores in global variables has been common practice for many Svelte devs pre SevelteKit. In SPA scenarios people got away with it, but now these practices backfire. That's not an inherit issue with Svelte, just bad practice.

So, IMO, this problem is not a technical one. What's needed is better training (don't use globals unless it's for true singletons; write functions as pure as possible). The docs could be more explicit about this, I guess, but it's clearly mentioned.

I don't want to sound condescending. I just don't believe this is a bug that needs fixing.

[samal-rasmussen]

This is such a biggie it should be demonstrated in the tutorial and not just left as a detail you can easily gloss over in the docs.

[sjmueller]

"I don't want to sound condescending" usually precedes sounding condescending.

The problem isn't training, the problem isn't singletons. The problem is that stores are working one way in an SPA but then behaving dangerously on the server side. It's horribly unintuitive. Nobody would use a store globally for all users within an SPA, and literally nobody wants it to function this way on the server.

Make stores work the way people would expect them to work on the server. Anything else is a violation of expectations, a disappointment, and a failure of sveltekit.

[aloker]

When you say "Make stores work the way people would expect them to work on the server", do you literally mean stores only, or global variables in general? If the former, why only stores? If the latter - how would I go and create a "true" global variable? And how would such transparent request isolation work technically across all target environments?

As it is now, it's very consistent: a global variable is shared by every accessor. On the server this means every request, on the client, this obviously only means the one browser tab the app is running in. It's simple, no magic involved. Adding more magic to the system would not make it easier.

There are other places where you have to be aware of the difference of server side and client side (onMount, accessing the window object, etc). Why should global stores be different? It's a misconception that isomorphic apps remove server vs client from the equation.

I repeat myself, this is a question of training and documentation. And I do agree that there should be a clear explanation of all this as one of the first pages in the docs (maybe there is, I haven't checked recently).

[AlbertMarashi]

If you guys want to see this issue solved, please provided feedback on my proposal here #9878

[silverdilver]

I'm trying to wrap my head around all of this so hopefully someone can confirm if my understanding is correct.

I get if I make a store inside +page.server.ts outside of the load function, that object is effectively created once and then any changes to that are therefore shared between all requests which opens it up to leaking data.

What I'm struggling to wrap my head around is if a store is created using a store.ts file, and that is created/used within a +page.svelte, can data leak on the server that way?

Eg Skeleton has a warning around this for some of their utilities, as behind the scenes they use stores which work via exporting the store as a const

Is this only a danger if it's used within a load function (both +page.server.ts & +page.ts), or is it also a risk to use that within +page.svelte?

[nickyhajal]

It is a risk because when +page.svelte is generated by the server for SSR, then it will again be using shared state between requests.

Using a context for the store on the layout or page forces the it to be recreated on each request, even on the server.

[Maxiviper117]

I had a somewhat similar head scratch but came to an understanding here: https://discord.com/channels/457912077277855764/1107384981921210418

[joaquimnetocel]

Could someone tell me if svelte 5 runes address this problem somehow?

[jdgamble555]

Nope, not out of the box - https://dev.to/jdgamble555/create-the-perfect-sharable-rune-in-svelte-ij8

[AlbertMarashi]

May be addressed by sveltejs/svelte#12947

[saturnonearth]

Holy moly why is this not stated in big red font in the docs.

[dummdidumm]

It's explained here: https://kit.svelte.dev/docs/state-management

If you read this already: What about this is unclear to you? If you didn't: Why didn't you find it? Which keywords/inbound links were missing to find it?

[anim8rDev]

Glad I stumbled across this. Is this issue only in regards to leaking sensitive data? Or would it also cause issues in another way? I.e. Values being changed or getting the wrong value unintentionally. I'd like to determine if all of my stores usage need updating or just the ones with sensitive data.

Thanks!

[jdgamble555]

Only stores declared outside of Svelte components in .ts files, but yes, all of those.

J

[sjmueller]

Who changed the title from: “Dangerous Store behavior with SSR”

to:

“Sharing a global variable across multiple requests is unsafe in SSR”

When I first created this bug as a github issue, you closed as invalid, and then moved into this discussion. I disagreed with your actions. Now almost two years later, the name is changed in what appears to be more effort at minimizing the significance of the issue.

It’s a bad look for sveltekit, which is a shame because there’s so much to like about the framework and the ecosystem.

[dummdidumm]

We changed the title because it better reflects what's going on. The issue is not related to stores (it's more general than that), and the title more clearly explains the problem ("what is dangerous about it?" vs "sharing it is unsafe, ok"), making it easier for people to find this thread - this is the opposite of downplaying it.

[jdgamble555]

I think the fact that Svelte is a compiler is exactly why this should be fixed inside Svelte. You guys do this automatically, as you say, with the $page store and other $app stores, why not have the ability to have the context automatic for any store!? This is what makes Svelte different from other frameworks.

At the very least, you should display an error when people try and put stores in a load function, or a warning for when global variables could be set by the user. This poses some challenges, but not impossible.

Having to set and get context to share state is a pain when this could be automatic. You could compile the external ts files or js files to a non-global context in the first place, for example, and some of this could be solved. There are many options here, but to claim this is a JS problem, when you guys chose to have your solution as context as your solution is not true. Context is a protocol, and you guys use a unique solution even for that (which is way better).

J

[sjmueller]

I share @jdgamble555's sentiment exactly: give a built-in store out of the box that works exactly like $page and $app using context. This should be the default option, since it would be used for 90% of everyone's needs.

[saturnonearth]

Who changed the title from: “Dangerous Store behavior with SSR”

to:

“Sharing a global variable across multiple requests is unsafe in SSR”

When I first created this bug as a github issue, you closed as invalid, and then moved into this discussion. I disagreed with your actions. Now almost two years later, the name is changed in what appears to be more effort at minimizing the significance of the issue.

It’s a bad look for sveltekit, which is a shame because there’s so much to like about the framework and the ecosystem.

Yea, oof

[dummdidumm]

We have enhanced the docs to more clearly explain why shared state is a problem in SSR and what to do instead: https://kit.svelte.dev/docs/state-management . You may also use clever workarounds like this library which makes it possible to use seemingly global writables in a SSR context and have them be locally bound if you only use them at component initialization on the server.

Note that the underlying problem - using global variables on the server - is not a problem related specifically to SvelteKit, this is a general problem/gotcha related to server environments. You could create a Next.js app, use a global variable across different components and run into the same problem. But in the case of Next.js/React you run into this much less because you have to use hooks to manage state in a reactive way which implicitly is scoped to a component tree, thereby avoiding this problem. In Svelte it's more apparent/common because of how easy it is to reuse global state across components and is taught that way in many docs. Historically this wasn't a problem because of the SPA-first world we lived in for so long. With SvelteKit now encouraging to use SSR, this comes back to bite us, as we now have to be more aware of these gotchas. We know that we have to make this more clear in the docs/tutorials and are looking for ways to improve this.

[sjmueller]

I read the docs you linked, and I'm impressed with how the challenges of SSR stores are explicitly described, and that a solution (via context) is offered.

Your response also shows that you're deeply aware of the challenges and all of the reasons why it's a tricky area for sveltekit. Thanks for approaching this with curiosity and humility.

[byte-my-briefs]

I agree with @sjmueller and likewise appreciate the response, @dummdidumm. I think a few simple changes to the documentation on the official Svelte store page and in the Svelte tutorial would be massive in raising awareness among beginners on this issue. The first is the top search result for "svelte store" and the latter is, of course, most newbies' first introduction to Svelte and SvelteKit.

Though the two links above are Svelte-related resources (not Svelte_Kit_), I think most newcomer's expectation is (understandably) that behavior would remain the same between the two.

I will be writing an in-depth comment here later today summarizing the state of the issue for any one who stumbles across this in the future and recommending the two (small) changes to the documentation I think would have the biggest impact in addressing the confusion around this issue. With runes inevitably coming soon, I assume we will see more and more state moved to the module level, so we may also wish to address any potential foot-guns involved with that as well.

[wiverson]

Suggestion - tweak store to have three options.

The default would be one that uses the existing store behavior when run on the client and a server/context aware one when run on the server. Then add an explict server/shared state option with a big warning on it.

Something like adding an enums for store initialization like:

standard (default, client global, server w/context)
client only
server only
shared state server (with warning in docs)

This would make the store work more or less how everyone expects while still allowing an option for running on the server.

[saturnonearth]

sentiment exactly: give a built-in store out of the box that works exactly like $page and $app using context. This should be the default option, since it would be used for 90% of everyone's needs.

Especially considering that Svelte and Sveltekit are often used interchangeably. The line is often blurred where Svelte starts and SvelteKit begins - that was kinda the whole point of these frameworks in the first place (imo).

[link--11]

I'd like to share my perspective as someone who just run into this issue while trying to add some server side rendering to a previously client-only app. I'm keeping most of my shared application state in stores that are exported from js files, from where it is imported in the svelte files that need it. From what I can tell, this pattern is common in Svelte, and even used in the official tutorial.
Now, for the page to be fully populated on page load already, I simply passed the data from the load function to the store during the root component's initialization — and only after a few days noticed the issue with that, when loading the page in a different browser and seeing a different user's data 😅 (luckily still in development).

In my opinion there are two issues with the current approach:

1. It assumes everyone reads the docs. As great as that would be, there will always be users who will at best skim through the first pages until they run into a specific issue that creates the need for further reading.
   In a case like this, where it's very easy to create a pretty big problem, the framework should make a better effort to protect its users. If possible, a console warning when trying to set global store state during SSR would be very much appreciated, since that practice is heavily discouraged in the docs, and most people doing it probably aren't aware of the implications.

2. The proposed solutions aren't great. It might be a bit subjective whether you prefer to put stores into the global context, or pass them around through the context API, but it can't be denied that many client-only Svelte apps do use global state. If they want to add in some SSR, that will require changing state handling patterns, which can be quite inconvenient in more complex projects.
   One the reasons I switched to Svelte in the first place was that SvelteKit provided a unified way to build all kinds of apps and seamlessly switch between client-only and SSR modes, but if they require different approaches to handling state, that's not really the case anymore.

I don't know how most of the other frameworks handle this problem, but in Vue for example, the official solution for handling complex shared state (Pinia) is "SSR-safe" by default, for good reason. Svelte stores are of course not the same, but comparable in that they are the framework's recommended solution for shared state. Is there any reason why they should NOT be SSR-safe, aside from some added complexity / impact on performance? I can't come up with any use case that would rely on the current behaviour, whereas obviously there are issues that come with it, as evident by this lengthy discussion.

[saturnonearth]

...shared state (Pinia) is "SSR-safe" by default...

Where's the fun in that when I can go "SSR-dangerous"

[AlbertMarashi]

EDIT 1
Hi everyone,

I have implemented a Draft PR prototype that implements request-level store isolation during server-side rendering using node's AsyncLocalStorage functionality which enables the ability to provide different global contexts to code running within isolated async functions (as is done in the server response generation code)

#12215

EDIT 2
Please see the following proposal:

• Proposal for Svelte 5: Universal Reactivity & Safe SSR Global State? svelte#12947

Would love to get your feedback and finally solve this important issue

See:

• SvelteKit 3 Ideas and Discussions #13336

[mightychoc]

Huntabyte did a video on this discussion and proposes to leverage a class implementation when using Svelte 5. Here's a link to the video if anyone's interested: Youtube: Global Stores Are Dangerous

[AlbertMarashi]

Hi everyone, I've proposed yet another solution to this problem which should hopefully solve this and many other issues in the following discussion page:

• SvelteKit 3 Ideas and Discussions #13336

Please feel free to upvote/comment/criticise and share your thoughts about the ideas within

[dylan1951]

It is totally astounding how so many of the examples in the svelte docs are examples of exactly what not to do in sveltekit. If you follow the docs and tutorials and use sveltekit (recommend) you will 100% have critical security bugs. It's literally by design. Totally insane.

[dylan1951]

At least put up a giant red flashing banner in the sveltekit docs that says "Please disregard everything you learned about svelte, we are going to do things totally differently, and if you don't then all your users' data will be exposed :)"

[CPritch]

My main gripe is all the exposing of db IDs in URLs/Search Params. Not a SvelteKit problem but if you're a new dev the docs will lead you down a dangerous path with no warning of this.

[AlbertMarashi]

My main gripe is all the exposing of db IDs in URLs/Search Params. Not a SvelteKit problem but if you're a new dev the docs will lead you down a dangerous path with no warning of this.

Why would exposing IDs in URL's be a security issue? The only scenario I could see where that might be a "security" risk is if you use incremental IDs and you don't want people to know how many objects exist in your application?

[CPritch]

Why would exposing IDs in URL's be a security issue? The only scenario I could see where that might be a "security" risk is if you use incremental IDs and you don't want people to know how many objects exist in your application?

Well considering most use incremental IDs instead of UUIDs you'd expect it to be the most common scenario. And you can just bump the ID in the route and load other resources into that page or form. Of course Auth covers protecting routes but there's examples outside of this context where you'd end up exposing data. I see comments all the time on the Svelte subreddit telling amateurs to do silly things and I think the docs could help assuage this.

Just seeing some links out or notes about being careful to consider server-client boundaries and exposing information. Things like salting a hash for a form etc. These are all things if you've been in the field a bit you just take for granted and these frameworks make these mistakes even easier now your FE+BE code is mostly colocated.

[saturnonearth]

At least put up a giant red flashing banner in the sveltekit docs

Yea this is my main gripe. In the least, the docs need to reflect that the mentality that you come into SvelteKit with, is different than that with Svelte alone.

[adiguba]

Hi,

SvelteKit will probably use an AsyncLocalStorage soon, with a getRequestEvent()allowing access to the request event :

• feat: add getRequestEvent to $app/server #13582

This may help to solve this problem.

Example : this code is incorrect on server-side because the user variable is shared by all request :

// This is a global variable, shared by all requests :
let user = null;

export function setUser(new_user) {
    user = new_user;
}

export function getUser() {
    return user;
}

But it could be replaced by something like that :

// This is a global variable, but its value is scoped to each request
// The array-function define the initial value of the variable on each request
let user = scopedVar( () => null );

export function setUser(new_user) {
    user.current = new_user;
}

export function getUser() {
    return user.current;
}

With the scopedVar() defined like that :
(I have not tested it with the PR, but it should work - I used a function like this in a nodejs backend)

/**
 * @template T
 * @param {() => T} initializer
 * @return { { current: T } }
 */
export function scopedVar(initializer) {
	const id = Symbol();
	return {
		get current() {
			const { locals } = getRequestEvent();
			if (id in locals) {
				return /** @type {T} */ (locals[id]);
			}
			// @ts-expect-error locals[id] has any type
			return (locals[id] = initializer());
		},
		set current(value) {
			const { locals } = getRequestEvent();
			// @ts-expect-error locals[id] has any type
			locals[id] = value;
		}
	};
}

[jdgamble555]

So the problem is already solvable with Context right now, it just requires a lot of boilerplate. If SvelteKit can have a simplified way of sharing state (or reactive state with $state) without the boilerplate, this could be useful. Your function above though is not much less boilerplate than we are already doing, but I am a huge fan of the getRequestEvent() being available everywhere.

Do we really need to create this boilerplate everytime we want to share a simple variable:

export function setUser(new_user) {
    user = new_user;
}

export function getUser() {
    return user;
}

export function scopedVar(initializer) {
...
}

This assumes your scopedVar function would be part of SvelteKit and not a custom function.

Ex: Nuxt has useState for this, although it is not a perfect solution. Angular has InjectionToken, which is amazing once you get past Angular's boilerplate itself.

I think in any case the docs need to be extremely clear on why this is necessary. I would bet there are more SvelteKit apps sharing state incorrectly and insecurely than securely.

J