Comment by block_hacks

To be clear, I’m not claiming this is some universal or inevitable failure mode, or that everyone running Next.js is compromised.

Every system has strengths and weaknesses. This is just one area where the tradeoffs aren’t always modeled correctly.

I don’t know what your setup looks like, how you deploy, or what your threat model is. You might already be accounting for this, or it might not matter for your use case. That’s fine.

The only point I’m making is that in modern SSR frameworks, execution can happen earlier than many teams expect — during deserialization, hydration, or framework setup — and when failures occur there, the signals look very different:

generic 500

no route handler invoked

no app logs

no auth context

That’s meaningfully different from traditional request-handling bugs that fail inside application control flow and leave traces people are used to seeing.

I’m not trying to persuade anyone or sell a solution. If you don’t find this relevant, you can safely ignore it.

But if you do run SSR in a security-sensitive environment, it doesn’t hurt to double-check where you believe the trust boundary actually starts — because in some cases it starts earlier than the app code.