SvelteKit/Supabase: Is it necessary to call getUser and getSession on every page in a SvelteKit app?

[KevinCase]

In the docs here on building a user management app with SvelteKit, the user's session is verified from the root +layout.server.ts which makes the session data available to all child pages:

// src/routes/+layout.server.ts
import type { LayoutServerLoad } from './$types'

export const load: LayoutServerLoad = async ({ locals: { safeGetSession }, cookies }) => {
  const { session, user } = await safeGetSession(); // Calls `getUser` and `getSession`

  return {
    session,
    user,
    cookies: cookies.getAll(),
  }
}

Then in the PageServerLoad function of child routes, the session is retrieved again using safeGetSession:

// /src/route/child/+page.server.ts;
export const load: PageServerLoad = async ({ locals: { supabase, safeGetSession } }) => {
  const { session, user } = await safeGetSession() // safeGetSession called again
  if (!session) {
    redirect(303, '/')
  }
 // rest of load function...
}

Why not use the session returned from the root level +layout.server.ts using const { session } = await parent(); in the child routes instead of calling safeGetSession() again? Is it necessary to call safeGetSession() in all child routes? Is there a risk of stale session data and error states?

Thanks!

[eurlexa]

https://dev.to/kvetoslavnovak/supabase-ssr-auth-48j4

[wesleysmyth]

Good question. You should not use await parent() to get the session in child routes, and here's why:

Why safeGetSession is called again in child routes

1. Security: The parent() data comes from the layout's load function, which runs on both server and client. When SvelteKit navigates client-side, parent() returns cached data from the layout — but that session data could be stale or tampered with. Calling safeGetSession() directly in each +page.server.ts ensures the session is validated server-side on every request.

2. safeGetSession is cached per-request: Supabase's SvelteKit helper caches the result of getUser() within a single request lifecycle (via locals). So calling safeGetSession() multiple times in the same request (layout + page) only makes one actual call to Supabase Auth — subsequent calls return the cached result.

Request comes in
  → +layout.server.ts calls safeGetSession() → hits Supabase Auth API (1 call)
  → +page.server.ts calls safeGetSession()   → returns cached result (0 calls)

3. parent() creates a waterfall: Using await parent() in a page load forces SvelteKit to wait for the layout load to complete before the page load can start. With safeGetSession() directly, both can run in parallel.

The actual cost

Approach	Auth API calls per request	Waterfall
safeGetSession() in each load	1 (cached)	No — parallel
await parent() in page load	1	Yes — sequential

Both make the same number of Supabase API calls, but parent() is slower due to the waterfall.

When await parent() is fine

If you only need the session for UI rendering (not for gating access), you can use parent() in +page.ts (not +page.server.ts):

// +page.ts (universal load — runs on client too)
export const load: PageLoad = async ({ parent }) => {
  const { session } = await parent();
  // Use session for UI state, not for authorization
  return { isLoggedIn: !!session };
};

When you MUST use safeGetSession()

Any time you're making a security decision (redirect if not authenticated, fetching user-specific data from DB):

// +page.server.ts
export const load: PageServerLoad = async ({ locals: { supabase, safeGetSession } }) => {
  const { session, user } = await safeGetSession();
  if (!session) redirect(303, "/login");

  // Safe to use user.id for DB queries
  const { data } = await supabase
    .from("profiles")
    .select("*")
    .eq("id", user.id)
    .single();

  return { profile: data };
};

TL;DR

Call safeGetSession() in every +page.server.ts that needs auth. It's cached per-request (zero extra API calls), avoids waterfalls, and is the secure pattern because it validates the JWT server-side every time rather than trusting cached client data.

[KevinCase]

Hey thanks for the detailed answer. What about calling ‘safeGetSession’ in hooks.server.ts, rather than within the load function? My understanding is hooks act as middleware and run on every request to the server.

[rChaoz]

Yes, that's the recommended approach I think. Authenticate and place the result in event.locals, it can then be used anywhere (page/layout load, endpoints etc.)