Next.js Security Checklist: 25 Essential Steps

Define a strict CSP in `next.config.js` headers or middleware. Start with `default-src 'self'` and add specific sources for scripts, styles, and images. CSP blocks XSS attacks by preventing the browser from executing unauthorized scripts, even if an attacker injects them.

Add `Strict-Transport-Security: max-age=63072000; includeSubDomains; preload` to your response headers. This forces browsers to use HTTPS for all future requests to your domain, preventing SSL stripping attacks on subsequent visits.

Set `X-Frame-Options: DENY` to prevent clickjacking (your page embedded in a malicious iframe) and `X-Content-Type-Options: nosniff` to prevent MIME type sniffing. These are simple headers that block entire categories of attacks.

Set `Permissions-Policy: camera=(), microphone=(), geolocation=()` to explicitly disable browser APIs your app doesn't need. If an attacker injects a script, they can't access these APIs even if the user grants permission.

Add middleware that redirects HTTP requests to HTTPS. While hosting platforms like Vercel handle this automatically, self-hosted deployments need explicit redirect logic. Check `request.headers.get('x-forwarded-proto')` behind reverse proxies.

Use Next.js middleware to check authentication on every request to protected routes, not just in page components. Middleware runs before the page loads, preventing any protected content from being rendered or sent to unauthenticated users.

Never rely solely on middleware for authorization. Middleware can be bypassed in edge cases (rewrite rules, direct API calls). Always re-check the user's session and permissions in Server Components and API route handlers as a defense-in-depth measure.

Set `HttpOnly` (no JavaScript access), `Secure` (HTTPS only), and `SameSite: Lax` or `Strict` on session cookies. Next.js API routes can set cookies via `cookies().set()` with these options. Without HttpOnly, an XSS attack can steal session tokens.

Every Server Action should check the user's role before performing mutations. Server Actions are exposed as HTTP endpoints — an attacker can call them directly without going through your UI. Always validate permissions at the action level, not just the component level.

Add rate limiting to login, registration, and password reset API routes. Use a library like `rate-limiter-flexible` with a Redis or in-memory store. Without rate limiting, attackers can brute-force credentials or abuse password reset flows.

Server Component props are serialized and sent to the client for hydration. If you pass a database connection string or API key as a prop, it appears in the HTML source. Keep secrets in server-only code and use the `server-only` package to enforce the boundary.

Add `import 'server-only'` to any module that contains secrets, database queries, or internal business logic. This causes a build error if the module is accidentally imported from a Client Component, preventing server code from leaking into the browser bundle.

Validate and sanitize all form data received by Server Actions using a schema validation library like Zod. Server Actions receive raw FormData from the client — treat it like any untrusted input. Never interpolate user input directly into database queries.

Inspect the RSC payload (view page source, look for the `__next_f` script tags) to verify no sensitive fields are being serialized. Common leaks include user objects with password hashes, internal IDs, or admin flags that the client shouldn't see.

Only variables prefixed with `NEXT_PUBLIC_` are exposed to the browser. Verify that database URLs, API secrets, and signing keys never use the `NEXT_PUBLIC_` prefix. Audit your `.env` files and `next.config.js` for accidental exposure.

Parse request bodies, query parameters, and URL params through Zod schemas in every API route handler. Return 400 with a descriptive error for invalid input. Unvalidated input is the entry point for injection attacks, type confusion, and business logic bugs.

Next.js automatically includes CSRF protection for Server Actions by checking the Origin header against the Host header. Verify this is working by testing from a different origin. For custom API routes, implement CSRF tokens manually using a library like `csrf`.

Never expose stack traces, database error messages, or internal paths in API responses. Catch errors in a wrapper, log the full error server-side, and return a generic message with an error code. Detailed errors give attackers a roadmap to your internals.

Set `bodyParser.sizeLimit` in your API route config or use middleware to reject oversized payloads. Without limits, attackers can send massive payloads that consume memory and crash your server. A 1MB limit is reasonable for most JSON APIs.

If your API routes are consumed by other domains, configure CORS explicitly with `Access-Control-Allow-Origin` set to specific domains, not `*`. For same-origin apps, ensure CORS is not accidentally enabled. Use the `cors` middleware pattern in your route handlers.

Run `npm audit` or use Snyk/Socket to scan your dependency tree. Fix critical and high severity vulnerabilities before deploying. Next.js apps often have hundreds of transitive dependencies — even one compromised package can inject malicious code.

Commit `package-lock.json` or `pnpm-lock.yaml` and use `npm ci` (not `npm install`) in CI. Without a lockfile, a compromised patch release of any dependency can inject malicious code into your next build without any code change on your part.

Add `poweredByHeader: false` to `next.config.js`. The `X-Powered-By: Next.js` header tells attackers exactly which framework you use, helping them target known Next.js vulnerabilities. Removing it adds no protection alone but reduces your information footprint.

Set `productionBrowserSourceMaps: false` (the default) in next.config.js unless you have a specific need. Source maps reveal your original source code, component structure, and comments to anyone who opens DevTools on your production site.

Add a GitHub Action or CI step that runs `npm audit --audit-level=high`, checks for leaked secrets with `gitleaks` or `trufflehog`, and optionally runs SAST with Semgrep. Automated scanning catches issues before they reach production and creates accountability.