Secrets storage in Next.js applications
Secret keys should be stored in environment variables. Only the Data Access Layer should access process.env to keep secrets from being exposed to other parts of the application.
Next.js · API reference · all subjects
data security
11 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Three recommended data fetching approaches
Next.js recommends three main approaches for fetching data: External HTTP APIs (for existing large applications and organizations), Data Access Layer (for new projects), and Component-Level Data Access (for prototypes and learning). It is recommended to choose one approach and avoid mixing them to maintain clarity for developers and security auditors.
Data Access Layer characteristics
A Data Access Layer should only run on the server, perform authorization checks, and return safe, minimal Data Transfer Objects (DTOs). This approach centralizes all data access logic, making it easier to enforce consistent data access and reduces the risk of authorization bugs. It also provides the benefit of sharing an in-memory cache across different parts of a request.
Server Components can access sensitive data safely
Server Components run only on the server and can safely access environment variables, secrets, databases, and internal APIs. Client Components, by contrast, must follow the same security assumptions as code running in the browser and must not access privileged data or server-only modules.
React Taint APIs for preventing private data exposure
To prevent accidental exposure of private data to the client, React Taint APIs can be used: experimental_taintObjectReference for data objects and experimental_taintUniqueValue for specific values. These are enabled in Next.js with the experimental.taint option in next.config.js. Taint is an additional layer of protection; data should still be filtered and sanitized in the Data Access Layer before passing to React's render context.
Client input validation is mandatory
Client input must always be validated as it can be easily modified. This includes form data, URL parameters, headers, and searchParams. Never trust client-provided values like searchParams to determine access control; instead, re-verify using server-side mechanisms like authenticated tokens.
Authorization checks prevent IDOR vulnerabilities
Beyond authentication (is the user logged in?), authorization checks are required to verify the user has permission to act on a specific resource. This prevents Insecure Direct Object Reference (IDOR) vulnerabilities by checking that the user owns or has permission for the resource being accessed.
Data Access Layer pattern for mutations
Similar to reading data, a Data Access Layer can be applied to mutations. This keeps authentication, authorization, and database logic in a dedicated server-only module while 'use server' actions stay thin. The action then delegates to the DAL where all auth checks happen.
API Minimization principle for DTOs
When creating Data Transfer Objects (DTOs) from the Data Access Layer, only return data relevant for the specific query and not everything. This follows the API Minimization principle from W3C standards.
Functions and classes blocked from Client Components by default
Functions and classes are already blocked from being passed to Client Components by default, providing a built-in layer of protection against accidentally exposing server-only code.
Zero Trust model for Server Components in existing projects
When adopting Server Components in an existing project, follow a Zero Trust model. Continue calling existing API endpoints such as REST or GraphQL from Server Components using fetch(), just as you would in Client Components, treating all data as potentially untrusted.