The direct answer
Attach a response’s script nonce only to executable entries the trusted publisher independently intends to authorize. A matching nonce does not review the code, sanitize model output or establish that the delivered policy is enforced. Preserve the ordinary answer renderer’s script ban and hold any unsupported publisher or browser path.
Choose which code the publisher intends to execute
A console displays an ordinary generated release note and uses a small application bootstrap for trusted controls. A template refactor proposes adding the response’s nonce to every script entry it finds. That may make the page appear functional while erasing the distinction between the application’s code and content introduced through an untrusted path.
The SRI guide admits independently approved external bytes. This worksheet asks a separate publisher question: where should this response’s execution permission be attached? It selects one fixed inline application bootstrap, not an external dependency or dynamic loader. The answer renderer continues to exclude scripts and raw executable HTML.
Freeze a trusted-only response association
MDN’s CSP guide describes a fresh unpredictable nonce for each response, matching the policy and intended script elements. It warns against inserting nonces into every script tag, since that could authorize injected scripts. A nonce-based publisher therefore needs dynamic per-response association rather than a reused static token.
Invent response D-A, admitted console release R-A, trusted bootstrap S-A and ordinary note N-A. T-A is a symbolic nonce association, not a generated value. The publisher owns the policy and the S-A template slot. N-A supplies only admitted text to its separate display path; it controls neither executable slots nor nonce placement.
| Field | Proposed ownership |
|---|---|
| R-A / S-A | Independently reviewed fixed application code and provenance. |
| D-A / T-A | One supported response association with independently established generation policy. |
| Executable slot | Publisher-owned S-A entry only; no post-render blanket decoration. |
| N-A | Authorized short note through unchanged text-safe rendering. |
| Enforcement evidence | Actual effective response policy and browser path, separately established. |
The useful positive admits only this narrow publisher plan when every prerequisite holds. No nonce generator, template, browser path or enforcement evidence has been implemented or observed here.
Require the selected script policy to be effective
The script-src reference documents nonce admission for inline script elements and cryptographically secure generation with a unique value per request. Its compatibility notice says parts can vary. The opened guide was modified 22 March 2026; the reference was modified 12 August 2026. Neither establishes our deployed browser.
Select an enforced response-header policy whose reviewed effective script admission permits S-A through its response association. Require independent review of the entire policy composition, publisher transformations and actual supporting browser. This worksheet is not a complete CSP configuration and supplies no directive-precedence implementation. Unknown composition or delivery blocks admission.
Report-only policies are not enforced; a response can carry both an enforced policy and a separate reporting policy. Keep the two records distinct. A policy printed in source, a reporting notice or an expected token in a template does not establish the effective enforced response.
If S-A lacks its required association or the selected admission fails, keep the affected control unavailable. Offer only an independently reviewed trusted notice. Do not remove the restriction, switch loaders or treat the model’s assurance that the bootstrap is harmless as compatibility evidence.
Keep later trust expansion outside this plan
strict-dynamic propagates trust from a nonce- or hash-authorized root to scripts it loads. Our one-bootstrap profile excludes that delegation, additional script creation, host-based executable fallback and unsafe-inline, unsafe-eval or equivalent relaxation requests. A dependency that needs a different graph requires another design review.
The important distinction is the application’s admitted set, not whether a new keyword looks small. Record who owns each proposed executable entry, why it is necessary, its code baseline and which transformation can introduce it. A global helper that decorates unknown entries cannot supply that provenance. A valid response association also cannot make changed S-A code equivalent to its reviewed release.
Keep model text out of executable bootstrap source. The note must remain content through storage, rendering and reopened views. A friendly-looking note, a matching token or a successful formatting check grants no right to become application code. This worksheet leaves the separate iframe preview’s empty-token restrictions and the widget protocol unchanged.
Review eight inert publisher cards
Every card is PROPOSED_UNRUN. Symbolic labels are not nonce values, header contents, markup or browser observations.
| Card | Condition | Proposed disposition |
|---|---|---|
| 1. Ordinary note | Trusted S-A, supported D-A association and effective enforcement; N-A stays text. | Conditionally admit only this publisher plan. |
| 2. Missing association | S-A lacks the required matching response association. | Keep the feature unavailable; no weaker fallback. |
| 3. Reused token | Generation or per-response uniqueness is unsupported. | Reject the plan despite matching labels. |
| 4. Blanket decoration | A helper attaches the trusted token to model-supplied executable entries. | Reject the widened admission path; preserve the script ban. |
| 5. Delegating loader | A revision adds strict-dynamic or another code-loading graph. | Outside the selected one-bootstrap plan. |
| 6. Convenience relaxation | Unexpected script behavior is repaired by widening executable permission. | Hold for redesign; availability is not code provenance. |
| 7. Reporting only | Only a reporting policy is known, or browser/effective delivery is unresolved. | No enforcement claim; hold the missing prerequisite. |
| 8. Independent denial | Association matches but release provenance, note rights or later resource use fails. | Deny independently; a nonce supplies no override. |
State the remaining boundary honestly
Actual publisher ownership, approved code, secure generation, response association, complete policy composition, supported browser, content/resource admission and current rights are unimplemented or unknown. Those gaps block real admission. This plan establishes no no-network, confidentiality, safe-code, sanitization, action-approval or universal XSS guarantee.
No nonce, header, script, markup, browser, DOM, policy configuration or runtime fixture was created or exercised for these cases. Documentation research and editorial writing are separate. Boundary remains prelaunch with planned request-path checks; its mock policy evidence does not implement or validate this browser publisher.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.