Most teams treat security as a phase. You ship, an audit hands you a list, and you spend a sprint patching things that should never have been wrong. I work from the opposite end. The defaults get chosen up front so the insecure version is the one you have to go out of your way to write. Get the defaults right and the audit finds nothing, because there was nothing to find.

This page is the spine of "secure by default": four rules with the reasoning behind each, the wrong way and right way side by side, then a walkthrough that hardens a typical app. Server Components moved data fetching onto the server. That is a real improvement, but it also moved the security boundary into a place a lot of frontend code never had to think about. The framework gives you good defaults. Your job is to not fight them.

The four rules

These are not aspirations. They are the load-bearing rules, and each one has a failure mode that ships to production when you ignore it.

By default, environment variables live only on the server. Next.js inlines a variable into the client bundle only when its name starts with NEXT_PUBLIC_, and that inlining happens at build time. So the prefix is not a convenience toggle. It is a one-way door that bakes the value into shipped JavaScript where anyone can read it.

// WRONG: this key is now inlined into the browser bundle.
// Every visitor can read your secret key in the page source.
const stripe = new Stripe(process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY!)

import 'server-only'
 
// Right: unprefixed, read on the server, never sent to the client.
// The server-only import makes a client import a build error.
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)

Form fields, search params, headers, and bracketed route segments like /[slug]/ are all user input. In Next.js 16 params is a Promise you await, and what you get back is still attacker-controlled. Trusting it directly is how you get privilege escalation from a query string.

// WRONG: trusting a query param as an authority signal.
export default async function Page({
  searchParams,
}: {
  searchParams: Promise<{ isAdmin?: string }>
}) {
  const { isAdmin } = await searchParams
  if (isAdmin === 'true') {
    return <AdminPanel /> // anyone can append ?isAdmin=true
  }
}

import { cookies } from 'next/headers'
import { verifyAdmin } from '@/lib/auth'
 
// Right: the authority signal comes from a verified server check,
// not from a value the client can type into the URL.
export default async function Page() {
  const token = (await cookies()).get('AUTH_TOKEN')
  const isAdmin = await verifyAdmin(token)
  if (isAdmin) {
    return <AdminPanel />
  }
}

This is the rule people violate without noticing, because the app looks correct. The admin link is hidden from non-admins, so it feels locked. But an exported Server Action is reachable by a direct POST request even if no component renders it, and a page-level auth check does not extend to the actions defined inside that page. The server entry point has to verify the caller on its own.

'use server'
import { db } from '@/lib/db'
 
// WRONG: no check inside the action. The page hiding the button
// does nothing. This is reachable by a direct POST.
export async function deleteAllRecords() {
  await db.record.deleteMany()
}

'use server'
import { auth } from '@/lib/auth'
import { db } from '@/lib/db'
 
export async function deleteAllRecords() {
  const session = await auth()
  if (!session?.user?.isAdmin) {
    throw new Error('Unauthorized') // the check that actually matters
  }
  await db.record.deleteMany()
}

Authentication asks "who are you". Authorization asks "are you allowed to act on this resource". Skipping the second question is how you get Insecure Direct Object Reference (IDOR): a logged-in user passes someone else's postId and your action happily deletes it. Every credential, database role, and access policy should grant the minimum needed and nothing more.

Input-handling rules, by context

The four rules tell you to validate input. These tell you exactly what to do for each kind of input you actually encounter, so the rule fires at the right moment instead of staying abstract. Each one is a trigger you watch for, the rule to apply, and the shape of the fix. Hand this list to an AI and it knows when each rule applies, not just that it exists.

// AVOID: string interpolation is SQL injection.
const rows = await db.query(`SELECT * FROM users WHERE email = '${email}'`)
 
// PREFER: a parameter placeholder. The driver escapes it; input
// can never break out of the value position.
const rows = await db.query('SELECT * FROM users WHERE email = $1', [email])

import { z } from 'zod'
 
// Validate the shape, then lowercase so 'A@x.com' and 'a@x.com'
// are one identity. Store and compare the normalized form.
const EmailInput = z.object({ email: z.string().email().toLowerCase() })
const { email } = EmailInput.parse(formData)

// AVOID: raw HTML from a user is stored XSS.
<div dangerouslySetInnerHTML={{ __html: comment.body }} />
 
// PREFER: render as text (React escapes it). If you truly need
// HTML, sanitize first with a library like isomorphic-dompurify.
<div>{comment.body}</div>

const MAX = 5 * 1024 * 1024 // 5 MB ceiling
if (file.size > MAX) throw new Error('Too large')
 
// Trust the bytes, not the client's claim. Sniff the magic number,
// store under a random key, never the user's path.
const key = `${crypto.randomUUID()}.${extFromSniffedType(file)}`

// AVOID: open redirect. ?next=//evil.com walks your users off-site.
redirect(searchParams.next)
 
// PREFER: only redirect to paths you recognize.
const safe = new Set(['/dashboard', '/settings', '/'])
redirect(safe.has(searchParams.next) ? searchParams.next : '/dashboard')

// Cap requests per identity per window before doing the work.
const ok = await rateLimit(`contact:${ip}`, { max: 5, windowSec: 60 })
if (!ok) return new Response('Too many requests', { status: 429 })

Hardening a typical app

The rules above describe the destination. Here is the path. Each step is a concrete change you can apply to an existing app, working from the outside in: lock the secrets, build the layer that says no, validate the inputs, control the outputs, then set the trust boundary for the proxy.

import 'server-only'
 
// Only this layer reads connection secrets. Nothing else imports
// process.env for data access, which keeps the blast radius small.
export const db = createClient({
  url: process.env.DATABASE_URL!,
  token: process.env.DATABASE_TOKEN!,
})

import 'server-only'
import { auth } from '@/lib/auth'
import { db } from '@/lib/db'
 
export async function deletePost(postId: string) {
  const session = await auth()
  if (!session?.user) {
    throw new Error('Unauthorized') // authentication
  }
 
  const post = await db.post.findUnique({ where: { id: postId } })
  if (!post) {
    throw new Error('Not found')
  }
 
  // Authorization: prove ownership before mutating. This single
  // line is the difference between a safe action and an IDOR hole.
  if (post.authorId !== session.user.id) {
    throw new Error('Forbidden')
  }
 
  await db.post.delete({ where: { id: postId } })
}

'use server'
import { z } from 'zod'
import { deletePost } from '@/data/posts'
import { revalidatePath } from 'next/cache'
 
const DeleteInput = z.object({ postId: z.string().uuid() })
 
export async function deletePostAction(formData: FormData) {
  // Reject malformed input before it reaches the DAL.
  const { postId } = DeleteInput.parse({
    postId: formData.get('postId'),
  })
 
  await deletePost(postId) // auth + authz live inside the DAL
  revalidatePath('/posts')
  return { success: true }
}

import 'server-only'
import { auth } from '@/lib/auth'
import { db } from '@/lib/db'
 
export async function getPostDTO(postId: string) {
  const session = await auth()
  if (!session?.user) {
    throw new Error('Unauthorized')
  }
 
  const post = await db.post.findUnique({ where: { id: postId } })
  if (post?.authorId !== session.user.id) {
    throw new Error('Forbidden')
  }
 
  // A Data Transfer Object: only the fields the client renders.
  return { id: post.id, title: post.title, body: post.body }
}

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
 
export function proxy(request: NextRequest) {
  const token = request.cookies.get('AUTH_TOKEN')?.value
 
  // Coarse gate only. This is not authorization, it is a redirect
  // for visitors with no session. Ownership checks stay in the DAL.
  if (!token && request.nextUrl.pathname.startsWith('/dashboard')) {
    return NextResponse.redirect(new URL('/login', request.url))
  }
 
  return NextResponse.next()
}
 
export const config = {
  matcher: ['/dashboard/:path*'],
}