DEV Community

Cover image for Strict CSP Meets Prerendered HTML: A Next.js App Router Deep Dive
Tonal Mathew
Tonal Mathew

Posted on

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

#react #nextjs #security #webdev

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:

<script>
self.__next_f.push(...)
</script>
Enter fullscreen mode Exit fullscreen mode

These scripts are essential for React Server Components (RSC) hydration and streaming.

The problem? A strict CSP like:

script-src 'self'
Enter fullscreen mode Exit fullscreen mode

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:

No request = No nonce
Enter fullscreen mode Exit fullscreen mode

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:

<script
  src="/_next/static/chunks/..."
  integrity="sha256-..."
></script>
Enter fullscreen mode Exit fullscreen mode

Great. But then we inspected the generated HTML. The external scripts were protected — the inline scripts were still there:

<script>
self.__next_f.push(...)
</script>
Enter fullscreen mode Exit fullscreen mode

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:

10 pages      → Probably insignificant
100 pages     → Usually manageable
1000+ pages   → Worth measuring
Enter fullscreen mode Exit fullscreen mode

To be precise, the challenge isn't really the number of pages — it's the number of unique inline scripts.

You could have:

1000 pages → same scripts reused everywhere → small CSP header
Enter fullscreen mode Exit fullscreen mode

Or:

100 pages → unique inline scripts per page → large CSP header
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)