- Ya
- 20 Agosti 2026, 04:25 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 00ee182
Re-lands the security headers after I took the site down with them, minus the one directive that did it, plus a build guard so it cannot happen again. WHAT BROKE. `require-trusted-types-for 'script'` is only survivable if a policy named `default` exists before the first DOM sink fires. Mine never ran. The policy was rendered from app/[locale]/layout.tsx, which looks like a root layout and is not — there is an app/layout.tsx above it — and `next/script strategy="beforeInteractive"` is only honoured in the true root. Next downgrades it elsewhere without a warning. So the page loaded, hydration started, and every sink threw: react-dom on `innerHTML`, Turbopack's chunk loader on `script.src`, nine TrustedScriptURL refusals, then Next's client-side error screen. My reasoning had been that no sink could fire before the policy because all 78 flight-data pushes are in the body. That was the wrong question. The framework's own `<script async>` tags are hoisted into <head> and execute as soon as they download — they do not wait for the body, and they are the ones that threw. MOVING IT TO THE REAL ROOT DID NOT FIX IT. Measured, not assumed: app/[locale]/layout.tsx policy @ 12,678 first async script @ 1,593 app/layout.tsx (root) policy @ 12,678 first async script @ 1,730 React hoists `<script async src>` above anything a layout renders, so there is no position in the tree that wins. The remaining options are worse than the problem: rewriting the HTML stream in middleware puts a per-request transform in front of every prerendered page and breaks streaming, and a nonce-bearing CSP needs headers(), which drops ~200 routes off static rendering and costs the prefetching this site depends on. So Trusted Types ships as **************** The directive is deployed and violations are visible; a report-only header cannot block anything. The Lighthouse item stays red, and that is the honest state rather than a pass-through policy that would make it green while protecting nothing. The guard is the real deliverable. **************** fails the build if the directive is enforced while the policy is emitted after the first async framework script, and prints the two offsets and the fix. It runs on prebuild and in npm test. Nothing about this failure is visible to types, lint or the build — only the byte order of the emitted HTML — which is why it needed a check rather than a comment. Enforced and verified against the real standalone server: CSP with no trusted-types directive, COOP same-origin, Referrer-Policy, Permissions-Policy, X-Content-Type-Options. Audited the served page resource by resource against the finished policy: zero blocked, and 'unsafe-inline' covers all 86 inline scripts.