Shipping securely on a budget

How to add security headers in Next.js (including CSP)

July 18, 20266 min read

A control panel of switches in low light — protections configured to travel with every response.

Next.js doesn't send security headers by default — you add them. It's a small change, with one genuinely tricky part: a Content-Security-Policy strict enough to help without blocking your own app. Here's the shape of it, and the trap to avoid.

Next.js changes fast, and where headers belong has moved between versions. Check the approach against your installed version's docs before copying any tutorial — including this one. The concepts below are stable; the exact API may not be.

The straightforward headers

Most security headers are static strings that should ride on every response: Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. Next.js has a headers configuration that applies them across all routes — set them once there and you're done with this half.

If you're unsure what each of these does before you set it, that's the what are security headers rundown.

The hard part: CSP with a nonce

Content-Security-Policy is where people get stuck, because the easy version undermines the whole point. Adding 'unsafe-inline' to make your inline scripts work re-opens the exact hole CSP exists to close.

The correct approach for an app with inline scripts is a nonce: generate a random token per request in middleware, attach it to your CSP header and to each inline script, and the browser runs only the scripts carrying that request's token. It's more moving parts, but it's the difference between a CSP that protects you and one that's decorative.

Roll out CSP in report-only mode first. It reports what would be blocked without actually blocking anything, so you can find every script and style your own app depends on before you enforce — instead of shipping a policy that white-screens your homepage.

Generate it for your version

Because the right API depends on your Next.js version, the safest path is to have the model check your version and generate the version-correct setup, nonce and all:

paste into Claude or ChatGPT

Add security headers to my Next.js app. Check my Next.js version first and use the approach that's correct for it — don't guess from old tutorials.

Requirements:
1. Set these globally so every response carries them: Strict-Transport-Security (HSTS), X-Frame-Options (or CSP frame-ancestors), X-Content-Type-Options: nosniff, Referrer-Policy, and a Permissions-Policy.
2. Add a Content-Security-Policy. If my app uses inline scripts, use a nonce-based CSP generated per-request (via middleware) rather than 'unsafe-inline', and show me how to thread the nonce through.
3. Tell me the right place for these in MY version of Next.js (e.g. the headers() config, middleware, or wherever the current docs say), and flag anything that differs from older App Router / Pages Router advice.
4. Warn me about the common breakage: a too-strict CSP that blocks my own scripts/styles, and how to test in report-only mode first.

Show me the full config/middleware and tell me how to verify the headers are actually being sent.

Next.js's own CSP guide is the reference to check against your version.

Verify they're actually sent

Configuring headers and sending headers aren't the same thing — a redirect, a CDN, or a misplaced config can strip them. Confirm on the live URL that they arrive:

free tool · no loginSecurity headers checkScan your deployed Next.js app and confirm the headers you configured are actually being sent to browsers. No login.

Ship the headers — then watch the deployed app.

The scanner confirms your headers went live. Tell Me When Down watches the app after — SSL that lapses, a route that starts erroring, a site that goes down — free, no card, so a bad deploy doesn't slip past you.

Watch my appfree · no card required

more on shipping securely on a budget

The website launch security checklist nobody hands youYou get a deploy button, not a checklist — so most sites launch with the cert valid and nothing else checked. The four things to test from your URL in seconds, plus the code-side items that cost the most.Website down from an expired SSL certificateAn expired certificate is a full outage — every visitor hits a red warning, though the server's fine. Here's why auto-renewal still fails silently, why shrinking cert lifetimes make it likelier, and how to see it coming.My website says "Not Secure" — what it means and how to fix itThe "Not secure" label looks like a hack but usually isn't — it means your site isn't using HTTPS properly. Here's what the browser is really saying, and the common causes in plain language, fixed one by one.What are security headers? A plain-English guideSecurity headers tell the browser how to behave safely — refuse HTTP, block framing, don't guess file types. Here's what each of the ones that matter actually does, and why almost every new site ships without them.SSL certificate expiry monitoring: why the calendar reminder failsA calendar reminder assumes your renewal works. But auto-renewal is a background job that fails silently, and cert lifetimes are dropping to 47 days by 2029. Here's why manual SSL tracking breaks, and what to monitor instead.Secure, HttpOnly, SameSite: the cookie flags that matterThree small flags — Secure, HttpOnly, SameSite — decide whether your session cookie is a locked token or the easiest thing to steal on your site. Here's what each closes, and how to check which your cookies set.

spot something wrong or out of date? [email protected] — we'll fix it

All posts