Security Hardening for Next.js

Security is not a feature you bolt on at the end of a project; it is a property of the whole system. In Next.js, the line between server and client is porous by design: Server Components run during rendering, Server Actions accept mutations from the browser, route handlers expose HTTP endpoints, and middleware sits at the edge. Each layer is an opportunity to enforce security and a chance to get it wrong.

The guiding principle for a secure Next.js application is server-first verification. Anything the client sends is untrusted until validated on the server. Cookies, headers, form data, query strings, JSON bodies, and uploaded files are all attack surfaces. The server is the only place that knows the real session state, the real secrets, and the real business rules.

This guide covers defense in depth for Next.js 16: security headers and CSP, input validation and output escaping, CSRF and XSS prevention, authentication security, environment variable hygiene, dependency supply chain safety, and server-side protections such as SSRF and injection prevention. The goal is a practical, production-ready security posture that protects users without sacrificing performance.

HTTP response headers are the first line of defense. They tell the browser how to behave, restrict what can be loaded, and block entire classes of attacks before any JavaScript runs. Next.js lets you configure headers in next.config.ts and in middleware.ts. Use both: config for global defaults, middleware for request-specific values such as CSP nonces.

A solid baseline includes Strict-Transport-Security to enforce HTTPS, X-Frame-Options or frame-ancestors to prevent clickjacking, X-Content-Type-Options to stop MIME sniffing, and Referrer-Policy to control leaked referrer information. Add Permissions-Policy to disable browser features you do not need, such as microphone or geolocation.

Use next.config.ts for global static headers and middleware.ts only when a value must be dynamic, such as a CSP nonce. Middleware runs on the edge with limited Node.js APIs, so keep it lightweight.

Content Security Policy (CSP) is the most powerful header for preventing cross-site scripting and data injection. It tells the browser exactly which sources are allowed for scripts, styles, images, fonts, connections, frames, and other resources. A strict CSP can block inline scripts, inline styles, and external scripts from unexpected domains, even if an attacker finds a way to inject HTML.

The most secure CSP avoids 'unsafe-inline' for scripts. Because Next.js injects inline scripts for things like data hydration and error overlays, you must use a nonce: a random token generated per request that is added to both the CSP header and the <script> tags. Next.js supports this through middleware and the nonce option on script components.

In your layout, read the nonce from the request header and pass it to Script components or any inline scripts you control. Next.js uses the nonce automatically for its own inline scripts when it is present in the request headers. Never expose the nonce in a way that allows an attacker to predict it.

Deploy CSP in stages. Start with Content-Security-Policy-Report-Only and collect violations through a report-uri endpoint. Once the report noise drops to zero, switch to the enforcing header.

Every input is a potential attack vector. Next.js receives data from URL params, query strings, cookies, headers, JSON bodies, and FormData. The server must validate shape, type, length, and allowed values before using any input. TypeScript alone is not enough: it disappears at runtime, and attackers can send anything.

Zod is the most common choice in the Next.js ecosystem because it integrates cleanly with TypeScript. Define schemas at every server boundary: route handlers, Server Actions, and API clients. Reuse schemas on the client only for UX, and never trust client-side validation as a security control. Server Actions receive FormData by default, so validate expected fields and coerce types before use.

XSS prevention is a combination of validation and output encoding. Next.js escapes JSX output by default, which protects against many injection attacks. However, when you dangerously set inner HTML or render markdown, you must sanitize first. Libraries like DOMPurify for client HTML or sanitization libraries for markdown are essential. Never concatenate user input into HTML strings.

Cross-Site Request Forgery tricks an authenticated user into performing an unintended action on your site. The attacker embeds a malicious link or form on a third-party domain; the browser sends the victim's cookies along with the request, and the server accepts it as legitimate. Mutations that change state must verify that the request came from your own application.

Next.js Server Actions include CSRF protection by default because they are bound to a same-origin request and require a valid session. However, custom route handlers, external API endpoints, and forms submitted to third-party services need explicit guards. The strongest protection combines origin validation, same-site cookies, and anti-CSRF tokens for sensitive mutations.

Cookies are the transport for session state, so their attributes matter. SameSite=Lax blocks cross-site POST requests in modern browsers, which stops most CSRF attacks. SameSite=Strict is stronger but can break legitimate top-level navigation from external links. HttpOnly prevents JavaScript from reading the cookie, and Secure ensures it is only sent over HTTPS.

For operations outside Server Actions, issue a cryptographically random anti-CSRF token per session or per form. Store it in an HttpOnly cookie or embed it as a hidden field, and validate it on the server for every state-changing request.

Authentication security is about keeping sessions and credentials out of attacker hands. Even when you use a library like Auth.js or Clerk, you must understand the defaults and decide whether they match your threat model. Short-lived tokens, secure cookies, session rotation, and brute-force protection are the pillars of a production auth system.

Session cookies should be HttpOnly, Secure, and scoped with SameSite. Access tokens should be short-lived; refresh tokens can be longer but must rotate. Invalidate existing sessions on password change and log-out-from-all-devices. Brute-force protection should apply before authentication logic, using a Redis or database counter keyed by IP or account, and should return the same generic error for invalid credentials and locked accounts.

Brute-force protection should apply before authentication logic, using a Redis or database counter keyed by IP or account, and should return the same generic error for invalid credentials and locked accounts to prevent user enumeration.

Next.js distinguishes between server and client environment variables by the NEXT_PUBLIC_ prefix. Any variable with that prefix is inlined into the client bundle at build time and is visible to anyone who opens the browser dev tools. This is convenient for public configuration like API endpoints or analytics keys, but it is a security hole for secrets.

Keep secrets out of the client bundle entirely. Do not prefix database URLs, signing keys, API secrets, or private tokens with NEXT_PUBLIC_. Read them only in server code such as Server Components, route handlers, Server Actions, and middleware. If a value is sensitive, it should never be referenced in a client component or a .env variable that is sent to the browser.

Runtime checks catch missing secrets early. A missing database URL or signing key should fail the build or the first request, not manifest as a cryptic runtime error. Create a small validation module that parses process.env with a schema and throws if required values are absent. This pattern also gives you typed access to environment variables.

For production, consider a secrets manager instead of plain .env files. Services like AWS Secrets Manager, Azure Key Vault, Google Secret Manager, or HashiCorp Vault provide rotation, access auditing, and fine-grained permissions. If you must use .env files, never commit them to version control, restrict file permissions, and rotate leaked credentials immediately.

Third-party dependencies extend your attack surface. Every package you install can run build scripts, access the network, and read files during installation. A compromised dependency can exfiltrate secrets, inject malicious code into your bundle, or install additional malware. Supply chain security is about minimizing dependency exposure and detecting problems quickly.

Start by keeping dependencies current. Use npm outdated and npm audit regularly, treat high and critical advisories as deployment blockers, and review package-lock.json changes in every pull request. Lockfile integrity ensures reproducible installs and helps detect supply chain tampering.

Lockfile integrity is critical. The package-lock.json ensures that every install produces the same dependency tree. Commit it and review changes carefully. Be selective about authentication and security libraries: a small, well-audited library with a clear maintainer is usually safer than a large dependency that does more than you need.

Server-side code has direct access to databases, external APIs, and the file system. This power makes it dangerous. Injection attacks, unsafe redirects, server-side request forgery, and malicious file uploads are classic server-side vulnerabilities that Next.js applications are not immune to. The fix is always the same: validate, restrict, and never pass raw user input to powerful APIs.

SQL injection is prevented by using parameterized queries or an ORM. Never concatenate user input into SQL strings. Prisma, Drizzle, and other ORMs escape values automatically. If you write raw SQL, use prepared statements with placeholders. The same principle applies to NoSQL queries: use validated values, not raw user input, in query objects.

Server-Side Request Forgery (SSRF) happens when an attacker supplies a URL that your server then fetches, reaching internal services or cloud metadata endpoints. Always validate URLs against an allowlist of domains and protocols. Reject private IP ranges, localhost, and internal hostnames. Prefer pre-configured endpoints over user-supplied URLs whenever possible.

Open redirects are another common issue. Validate redirect targets against an allowlist of paths or domains, or use internal path-only redirects. Never redirect to a fully qualified URL from user input without validation.

File uploads require extra care. Validate file types by inspecting magic bytes, not just the extension. Limit file size, store uploads outside the web root, rename them to random identifiers, and serve them through a controlled route rather than a direct URL. Never execute uploaded files or use their names directly in file system paths.

Use this checklist before shipping a Next.js application to production. It is not exhaustive, but it covers the most common and high-impact security controls. Go through every item, verify it in your environment, and document any exceptions with a risk assessment.