How do you prevent sensitive server-side data from leaking to the client bundle?

Question

Accepted Answer

Preventing sensitive server-side data from leaking to the client is critical in Next.js applications, especially with the App Router where Server Components and Client Components coexist. The main risk occurs when server-only code (database queries, environment variables with secrets) is accidentally imported into Client Components or passed as props across the server-client boundary [citation:4]. Next.js provides multiple layers of protection: the 'server-only' package to enforce module boundaries, a Data Access Layer to centralize and sanitize data, Data Transfer Objects (DTOs) to expose only necessary fields, and experimental React Taint APIs for additional defense-in-depth [citation:1][citation:8]. Use the 'server-only' package to mark modules that should never be imported into client components, causing build errors if accidentally imported [citation:1][citation:7]. Create a dedicated Data Access Layer (DAL) that centralizes all data fetching and authorization logic on the server [citation:8]. Implement Data Transfer Objects (DTOs) that return only the specific fields needed for rendering, never full database objects [citation:1][citation:8]. Never pass entire data objects from Server Components to Client Components—always filter to only what's needed [citation:8]. Use environment variables correctly: never prefix secrets with NEXT_PUBLIC_, which embeds them in the client bundle [citation:1][citation:4]. Consider enabling experimental React Taint APIs to mark objects or values that should never cross the server-client boundary [citation:2][citation:8]. The most fundamental protection is the 'server-only' package, which causes a build error if a module is accidentally imported into client code [citation:1][citation:10]. This is especially important for modules that access environment variables, databases, or internal APIs. Install it with `pnpm add server-only`, then add `import 'server-only'` at the top of any server-only file. If a developer later imports this module into a Client Component, the build will fail with a clear error message, preventing the leak from reaching production [citation:1][citation:7]. ```tsx
// lib/server/db.ts
import 'server-only';

export function getUserFromDB(userId: string) {
  // This function accesses server secrets and databases
  const config = process.env.INTERNAL_CONFIG ?? 'default';
  
  return {
    id: userId,
    email: 'user@example.com',
    passwordHash: 'bcrypt$2b$10$...', // NEVER expose this
    internalNotes: `VIP customer (config: ${config})`, // NEVER expose this
    name: 'Jane Developer',
  };
}

// If any Client Component imports this file, the build will fail:
// Error: 'server-only' cannot be imported from a Client Component module.
``` The Next.js documentation recommends creating a dedicated Data Access Layer for new projects [citation:8]. This internal library controls how and when data is fetched, performs authorization checks, and returns safe, minimal Data Transfer Objects (DTOs) [citation:8]. The DAL should only run on the server and should never return full database objects. Instead, it projects only the fields needed for rendering. This centralizes all data access logic, making it easier to enforce consistent security and reducing the risk of authorization bugs [citation:8]. ```tsx
// lib/server/auth.ts - Auth utilities
import { cache } from 'react';
import { cookies } from 'next/headers';

export const getCurrentUser = cache(async () => {
  const token = cookies().get('AUTH_TOKEN')?.value;
  const decodedToken = await decryptAndValidate(token);
  // Return class instance - helps prevent accidental serialization
  return new User(decodedToken.id);
});

// lib/server/user-dto.ts - Data Transfer Object
import 'server-only';
import { getCurrentUser } from './auth';

export async function getUserDTO(slug: string) {
  // Use parameterized queries for security
  const [rows] = await sql`SELECT * FROM user WHERE slug = ${slug}`;
  const userData = rows[0];
  const currentUser = await getCurrentUser();
  
  // Only return fields that are safe to expose
  return {
    username: userData.username,      // Public field
    // passwordHash: omitted!         // ❌ Never included
    // internalNotes: omitted!        // ❌ Never included
  };
}

// app/profile/[slug]/page.tsx - Server Component
import { getUserDTO } from '@/lib/server/user-dto';
import { ProfileClient } from './profile-client';

export default async function ProfilePage({ params }) {
  // This returns ONLY safe public data
  const profile = await getUserDTO(params.slug);
  
  // Pass only the safe DTO to the client component
  return <ProfileClient profile={profile} />;
}
``` A common mistake is fetching a full database object in a Server Component and passing it directly to a Client Component as props [citation:8]. This exposes all fields—including sensitive ones like password hashes, internal notes, or API keys—to the client bundle. Even if you don't render them, they're still present in

How do you prevent sensitive server-side data from leaking to the client bundle?

Prevent sensitive data leaks by using the 'server-only' package, creating a protected Data Access Layer, filtering data into safe DTOs, and leveraging React Taint APIs for defense-in-depth

How do you prevent sensitive server-side data from leaking to the client bundle?

Prevent sensitive data leaks by using the 'server-only' package, creating a protected Data Access Layer, filtering data into safe DTOs, and leveraging React Taint APIs for defense-in-depth

Scenario Questions

Follow-up Questions