Thinking About Data Security in Next.js – Access Layers, Server Components, and Preventing Data Leakage

Introduction

With the rise of Server Components in Next.js, traditional assumptions about frontend data access and security need to be reconsidered. This guide outlines secure data-fetching strategies and best practices to prevent accidental exposure of sensitive information.

Recommended Data Fetching Approaches

There are three main approaches:

• HTTP APIs: Best for large, existing applications
• Data Access Layer (DAL): Recommended for new projects
• Component-Level Access: Suitable for quick prototypes

Mixing these approaches is discouraged to maintain clarity and security consistency.

Using External HTTP APIs

In existing projects, you can fetch data from REST or GraphQL APIs inside Server Components:

const token = cookies().get('AUTH_TOKEN')?.value

const res = await fetch('https://api.example.com/profile', {
  headers: {
    Cookie: `AUTH_TOKEN=${token}`,
  },
})

This works well when backend teams operate independently or existing security policies are in place.

Creating a Data Access Layer (DAL)

For new projects, a DAL centralizes data access logic and improves security:

• Runs only on the server
• Performs authorization checks
• Returns minimal, safe Data Transfer Objects (DTOs)

Example:

export const getCurrentUser = cache(async () => {
  const token = cookies().get('AUTH_TOKEN')
  const decoded = await decryptAndValidate(token)
  return new User(decoded.id)
})

export async function getProfileDTO(slug: string) {
  const [rows] = await sql`SELECT * FROM user WHERE slug = ${slug}`
  const userData = rows[0]
  const currentUser = await getCurrentUser()

  return {
    username: canSeeUsername(currentUser) ? userData.username : null,
    phonenumber: canSeePhoneNumber(currentUser, userData.team)
      ? userData.phonenumber
      : null,
  }
}

Component-Level Data Access

For fast iteration, you might fetch data directly in Server Components. But this risks exposing sensitive data to the client:

// BAD: exposes full userData to client
return <Profile user={userData} />

Better approach:

export async function getUser(slug: string) {
  const [rows] = await sql`SELECT * FROM user WHERE slug = ${slug}`
  const user = rows[0]
  return { name: user.name }
}

Passing Data from Server to Client

On initial load, both Server and Client Components run on the server but in isolated module systems:

• Server Components can access secrets, databases, and internal APIs
• Client Components must follow browser-like security rules

Using Taint to Prevent Leakage

React provides experimental APIs to mark sensitive data:

• experimental_taintObjectReference
• experimental_taintUniqueValue

Enable in next.config.js:

module.exports = {
  experimental: {
    taint: true,
  },
}

Security Best Practices

• Environment variables are server-only unless prefixed with NEXT_PUBLIC_
• Functions and classes are blocked from being passed to Client Components
• Use server-only to prevent server code from running on the client

// lib/data.ts
import 'server-only'

Conclusion

Data security in Next.js requires thoughtful design of access layers, clear separation between server and client environments, and use of protective tools like DAL, taint, and server-only. By following these practices, you can build secure, scalable, and trustworthy applications.