A strict CSP killed one form in production, and every monitor stayed green

A nonce is worth something only because it is minted per request, and a page baked at build time has no request to mint from, so the framework has nothing to stamp onto the script tags it writes ^[7][8]. It does not fail loudly at that point. It emits the tags bare, and the middleware still attaches a header demanding a nonce to the response carrying them ^[10]. With no unsafe-inline for scripts anywhere in the policy, an un-nonced tag had nothing else to match against, so the browser blocked everything from main-app.js down ^[6][11].

The invisibility comes from what the HTML does next. React never hydrated, so no component mounted; the bot-check widget, which arrives by script, never drew, and the submit handler never attached ^[12]. A button inside a form with no handler still does its native job, which is submit and reload, so the user got a flicker and the same page back ^[13]. No request of any kind left the browser ^[14].

Six health signals were green, and every one of them samples the server: the error tracker, the server logs ^[2], the password-reset audit trail ^[3], curl against the endpoint, the page's 200 ^[4], and 3,500 passing tests ^[5][21]. None of them can see a failure that never leaves the client. The audit log deserves a second look, though, because it does not say "no recent requests". It records every password-reset request and holds zero, ever, which means the form had produced nothing at all for the entire life of that log ^[3][22]. This was not something that broke last Tuesday.

Finding it took about twenty characters in a console. Counting scripts that carry a nonce attribute returned 15 on /login, 19 on /pricing, and 0 on /forgot-password ^[18]. The gap is not marginal: the lowest healthy count sits fifteen above the dead one, so "greater than zero" is a clean pass or fail for any route in the build ^[23].

The repair is a single export in the page file, dynamic set to force-dynamic ^[19]. Its sibling /reset-password already had that line, because someone added it there once and did not add it to the twin page ^[20]. That is the part worth being unhappy about. Under a nonce policy, whether a form works at all is decided by whether an author remembered a per-file annotation, and the build output already prints the answer: any route flagged as statically prerendered that also ships interactivity is a dead route waiting for a user to notice ^[24]. Reading that table costs nothing next to the thing that actually caught this, which was a real browser pointed at the production build with the production header and the console open ^[17].