Strict CSP Meets Prerendered HTML: A Next.js App Router Deep Dive

*What started as a simple security hardening task on a Next.js 16 marketing site turned into a lesson about how App Router, SSG, PPR, and CSP actually interact.* ## The assumption Most developers assume: > Static Site Generation (SSG) + CSP = Easy That was my assumption too. But there's a catch. Next.js App Router injects multiple inline scripts into prerendered pages: ```html <script> self.__next_f.push(...) </script> ``` These scripts are essential for React Server Components (RSC) hydration and streaming. The problem? A strict CSP like: ```http script-src 'self' ``` blocks them. ## Why nonce-based CSP doesn't work here My first thought was: "No problem, I'll use nonce-based CSP." But nonces are generated per request, while SSG and PPR pages are generated at build time. Which means: ```txt No request = No nonce ``` So nonce-based CSP and prerendered HTML are fundamentally at odds. And here's the interesting part: this isn't really a **PPR problem**. It's a **prerendered HTML problem**. Whether you're using SSG, ISR, or PPR, the challenge is the same — the HTML already exists before the request arrives, so there's no opportunity to inject a request-specific nonce. ## Then we tried SRI The next idea seemed obvious: "If Next.js supports Subresource Integrity (SRI), doesn't that solve the problem?" After enabling SRI, external scripts looked like this: ```html <script src="/_next/static/chunks/..." integrity="sha256-..." ></script> ``` Great. But then we inspected the generated HTML. The external scripts were protected — the inline scripts were still there: ```html <script> self.__next_f.push(...) </script> ``` And that's when the distinction became clear: - **SRI** validates downloaded resources. - **CSP hashes** authorize inline execution. They solve different problems. SRI helped protect the external bundles, but it did not solve the CSP challenge around Next.js' inline RSC scripts. ## The discovery After auditing the site, we found: - 38 static/SSG pages - 6–9 executable inline scripts per page - 161 unique inline script hashes globally - Maximum *per-route* `script-src` length: 503 characters That last point matters: 161 SHA-256 hashes obviously can't fit in 503 characters. We generate a **per-route CSP header**, so each page's `script-src` only contains the hashes for the inline scripts that page actually serves. The 161 figure is the global total across all routes. At first I assumed hash-based CSP would become unmanageable. The data said otherwise. Because every page is statically generated, every inline script is deterministic at build time. Which means we can: 1. Extract inline scripts during the build 2. Generate SHA-256 hashes automatically 3. Add only those hashes to each route's `script-src` ## But hash-based CSP isn't a silver bullet There are tradeoffs: - Hashes must be regenerated on every build. - Framework-generated inline scripts can change between Next.js versions. - CSP generation becomes part of the build pipeline. - The CSP header grows as the number of unique inline scripts increases. - Very large applications can eventually run into HTTP header size limits imposed by browsers, CDNs, reverse proxies, or hosting platforms. For scale intuition: ```txt 10 pages → Probably insignificant 100 pages → Usually manageable 1000+ pages → Worth measuring ``` To be precise, the challenge isn't really the number of pages — it's the number of **unique inline scripts**. You could have: ```txt 1000 pages → same scripts reused everywhere → small CSP header ``` Or: ```txt 100 pages → unique inline scripts per page → large CSP header ``` At some point, you're not just solving a security problem anymore. You're managing CSP infrastructure. ## The most interesting takeaway The solution wasn't "use nonces." It wasn't "use SRI." And it definitely wasn't "hash everything." The real lesson was understanding the constraints imposed by the rendering model. The common discussion is often framed as: ❌ PPR vs CSP When the real discussion is: ✅ Nonce-based CSP vs Prerendered HTML Once I started looking at it through that lens, the tradeoffs became much clearer. Different applications will likely arrive at different answers: - Some will choose SSR + nonces. - Some will choose SSG/PPR + hashes. - Some may accept carefully documented CSP exceptions. There isn't a universal solution. Only tradeoffs. And that's what made this investigation far more interesting than I expected. *Curious how others are handling CSP with Next.js App Router, SSG, or PPR in production — drop a comment.*