Did you know? An AI answer can contain code as an example. A trusted website must display that content without silently granting it permission to execute inside a student’s browser.
Quick answer: render model text as data, deploy reviewed CSP nonces or hashes for trusted scripts, test policies in Report-Only mode and preserve independent authorization for tools.
This article extends How Super Intelligence Works. Exercises are fictional and illustrate real browser safeguards.
Contents and reading route
- 1. The short answer: generated text must not become trusted code
- 2. What a CSP header tells the browser
- 3. Why unsafe-inline is a dangerous shortcut
- 4. A nonce is a per-response random approval token
- 5. Nonce delivery and page caching interact
- 6. Hashes can be useful for static trusted scripts
- 7. script-src and default-src are not interchangeable
- 8. strict-dynamic extends trust under defined rules
- 9. CSP Report-Only is an observation phase
- 10. Violation reports are useful but potentially sensitive
- 11. A CSP violation does not prove hostile intent
- 12. Trusted Types helps protect dangerous DOM sinks
- 13. A model response is data, not a script permission
- 14. CSP is not a complete sanitizer
- 15. frame-ancestors and object-src have different uses
- 16. Safe preview isolation for educational documents
- 17. A fictional 90-policy-event ledger
- 18. An implementation sequence that can be tested
- 19. Negative tests for AI previews
- 20. What CSP cannot tell an agent
- 21. Six review questions and answers
- 22. Frequently asked questions
- 23. Authoritative sources and reading routes
1. The short answer: generated text must not become trusted code
Did you know? A perfectly helpful AI assistant can produce a useful explanation containing text that resembles executable HTML or JavaScript. If a website drops that text into an unsafe rendering surface, an attacker may persuade the browser to execute code that the service never authorized. Content Security Policy, or CSP, can reduce this risk by restricting which scripts and other resources a page may load or execute.
The practical approach is to keep user and model content as data, safely encode or sanitize it for the intended context, and enforce a reviewed CSP at the browser boundary. A strict policy may use unpredictable per-response nonces or approved script hashes, avoid broad unsafe-inline permission, and test violations in report-only mode before enforcement. CSP is a defense in depth, not a replacement for safe rendering and authorization.
2. What a CSP header tells the browser
A web server can send an HTTP Content-Security-Policy response header containing directives about resource loading and execution. Depending on its directives, the browser may restrict scripts, styles, images, frames, connections and other capabilities. The header is processed by the browser rather than by the language model that generated a page’s prose.
An application that displays an AI-generated lesson plan can use CSP to reduce opportunities for unexpected code execution. But the browser’s enforcement applies to the whole page context, including legitimate application scripts. A policy carelessly deployed without testing may disable buttons, educational diagrams or sign-in widgets. Security must be designed alongside the actual UI dependency map.
3. Why unsafe-inline is a dangerous shortcut
Allowing unsafe-inline in script-related CSP policy can permit code forms that a restrictive policy was meant to block. Many older websites use inline event handlers or inline script blocks, making it tempting to allow all such code when a feature breaks. That may restore the feature but also widen the surface for cross-site scripting.
A better migration moves legitimate logic into reviewed files or uses nonces and hashes under a strict policy, while treating imported text as untrusted. If an AI summary contains a phrase resembling onclick or a script tag, the page should present it as text rather than interpreting it as a new instruction from the site’s owner.
4. A nonce is a per-response random approval token
A CSP nonce is an unpredictable value generated by the server for a particular HTTP response. The response’s policy lists a nonce source, and a permitted script or style element receives the corresponding nonce attribute. The browser compares the values and may allow that element under the applicable directive. Reusing a predictable or static nonce across a site defeats the intended per-response design.
The legitimate script tag must receive the value through the server’s trusted rendering process. Do not copy it into arbitrary model-generated HTML, and do not let an untrusted document decide which elements receive the nonce. A nonce does not cleanse malicious JavaScript; it expresses permission to execute specific content in the response.
5. Nonce delivery and page caching interact
If pages with nonces are cached without care, many visitors may receive the same previously generated nonce. That weakens the freshness property the nonce was meant to provide. The exact caching risk depends on what is cached and how the policy and HTML are assembled, so the deployment must coordinate nonce generation with response caching.
For example, a tutoring portal may cache a static educational article while dynamically attaching an account widget. Its CSP handling needs a coherent rule for which HTML is reused and which approved scripts receive response-specific nonces. A CDN configuration that changes the CSP header but not the script attributes can break legitimate code; copying the same nonce into every response is not a security-quality shortcut.
6. Hashes can be useful for static trusted scripts
A CSP hash source can authorize particular inline script or style content by its digest under the relevant directive. This can be useful for stable content that does not change between responses. The allowed digest must match the relevant script bytes precisely according to the browser’s rules. If the trusted script changes, the policy must be updated accordingly.
For dynamic AI-generated output, preapproving arbitrary new hashes is not a good trust policy. An application that automatically hashes every untrusted snippet and adds it to CSP would authorize the very code it was meant to constrain. Decide which reviewed assets are genuinely trusted; model responses and reader comments should remain data.
7. script-src and default-src are not interchangeable
The script-src directive controls relevant script execution and fetching behavior. default-src acts as a fallback for certain fetch directives when a more specific directive is absent. A policy with a strong default can still have unsafe exceptions if its script-specific rule is overly broad. Conversely, a strict script policy does not automatically address every other resource category.
Review the full effective policy rather than looking for one comforting string. For an AI preview, controls for script, frame, form, object and network connections may have different purposes. The browser’s violation and debugging tools help reveal which directive applied. A model should avoid claiming that ‘default-src self’ means all injection risk has disappeared.
8. strict-dynamic extends trust under defined rules
The strict-dynamic source expression allows trust conferred through a nonce or hash to propagate to scripts loaded by an approved script through certain mechanisms. This supports applications that dynamically load script dependencies without constructing enormous host allowlists. It also requires care because a compromised trusted script can become a path for additional loads.
Do not interpret strict-dynamic as ‘automatically safe dynamic JavaScript’. Trust still begins with code that the application deliberately approved. MDN explains that source expressions such as host allowlists may be ignored in the relevant modern browser interpretation when strict-dynamic is active. Test the intended policy under supported browser versions.
9. CSP Report-Only is an observation phase
The Content-Security-Policy-Report-Only response header lets a team test a policy without enforcing it. Browsers can report violations that would occur, helping developers find legitimate resources or behaviors they need to address. This is useful during migration away from unsafe inline scripts.
Report-only is not a blocking protection. If a dangerous script would have executed under the current enforced policy, the report-only policy does not stop it. Teams should stage the rollout: gather reports, fix legitimate dependencies, review residual risk, then deploy an enforced Content-Security-Policy header. Report-only warnings are evidence to investigate, not proof that the site is already secure.
10. Violation reports are useful but potentially sensitive
CSP violation reports can reveal attempted resource URLs, document locations and in some configurations limited samples of blocked content. A debugging endpoint should validate incoming reports and protect user privacy rather than collecting full pages or private student documents. Attackers may also generate nuisance reports, so treat the telemetry as untrusted data.
An AI system that summarizes violation trends should group by validated policy, source and incident categories. It should not publish raw report payloads that include family URLs or query strings. Rate-limit collection, control retention and distinguish a browser extension or legitimate legacy script from a verified attack only when supporting evidence exists.
11. A CSP violation does not prove hostile intent
A browser may report a violation because an approved third-party widget changed its implementation, a CDN returned an unexpected asset or a school accessibility feature injected legitimate content. Other violations can indicate malicious input. The browser report generally records a policy conflict, not a final security diagnosis.
A safe agent should classify a violation as an observation, compare it against expected resources and then ask what code path produced it. Avoid automatically disabling the policy because one widget broke, and avoid accusing a student of hacking because their browser sent a report. Audit the facts before changing a sensitive security control.
12. Trusted Types helps protect dangerous DOM sinks
Trusted Types is a browser security mechanism that can restrict assignment of ordinary strings to certain DOM injection sinks, when supported and configured through CSP. It encourages reviewed policies for transforming untrusted input before it enters dangerous HTML or script interpretation contexts. This is especially relevant when applications render rich responses from an AI model.
A Trusted Types policy still needs a correct sanitizer or transformation. Calling unsafe input trusted because a function returns a TrustedHTML object would only rename the risk. The application should prefer text insertion APIs for ordinary prose, and use tightly reviewed rich-content rendering only where needed. Browser support and policy details must be checked for the deployment.
13. A model response is data, not a script permission
Consider a user asking an educational chatbot to explain how JavaScript works. The response may contain a code snippet that includes angle brackets or event-handler syntax. The application should render that example as code or safely escaped text. The model’s output has no authority to create an executable script, even if the code appears in a well-formatted tutorial.
Use component rendering, escaping and approved Markdown processing that does not allow arbitrary executable HTML. CSP adds a separate browser enforcement layer. It does not decide whether the answer is educationally correct, whether a hyperlink is trustworthy or whether the user’s account has permission to perform a tool operation.
14. CSP is not a complete sanitizer
CSP can block some script execution paths, but it does not make an unsafe HTML renderer correct or eliminate every DOM-based injection, navigation and data-flow risk. Some forms of user-interface deception or malicious linking may remain possible under a weak or incomplete policy. A server also still needs to validate input and protect external API actions.
For instance, a malicious document might ask an agent to ignore approval procedures. CSP cannot stop a model from misinterpreting those instructions if the application has already granted the agent excessive tool authority. Prompt-injection defenses, separate action authorization and safe browser rendering address different aspects of the trust boundary.
15. frame-ancestors and object-src have different uses
The frame-ancestors directive can restrict which sites are permitted to embed a page, supporting defense against certain clickjacking scenarios. The object-src directive controls relevant plugin-based embedded content; strict policies often set it to none. Neither directive is interchangeable with the script-src rule.
For a family portal, requiring appropriate framing and embedding restrictions may matter because a malicious page should not make a protected submit button appear inside an unexpected frame. But an app that legitimately embeds approved material needs a reviewed architecture. Avoid arbitrary wildcard permissions merely because a preview refuses to load.
16. Safe preview isolation for educational documents
An AI-generated report preview can contain Markdown, rich formatting and excerpts from uploaded files. A robust architecture treats that content as lower trust than the surrounding authenticated account shell. When complex HTML rendering is necessary, consider an isolated, appropriately sandboxed browsing context and a narrowly defined communication channel.
An iframe sandbox can constrain some capabilities, but its exact flags and origin behavior require care. Do not combine broad allowances in a way that recreates the parent page’s authority unnecessarily. A preview should never silently inherit permission to read private cookies or call sensitive account APIs simply because it is displayed beside a legitimate tutor dashboard.
17. A fictional 90-policy-event ledger
Imagine a practice roll-out that generates ninety CSP observations. Fifty-one are expected application resources that comply with the proposed strict policy. Fourteen are legacy inline handlers that need a safe rewrite. Eleven are third-party script loads requiring reviewed decisions. Seven are non-sensitive debug previews with an incorrect nonce. Seven are suspicious or unclassified input attempts needing investigation. The categories sum to 51 + 14 + 11 + 7 + 7 = 90.
It would be misleading to announce the policy is ready for enforcement merely because fifty-one examples passed. The twenty-five legacy or integration cases need engineering, the seven nonce issues require response configuration repair and the seven unknown cases require classification. All numbers are fictional teaching data, not reports from eduKate. A well-designed dashboard tracks resolved and unresolved blockers separately.
18. An implementation sequence that can be tested
Inventory existing inline scripts, styles, dynamically loaded dependencies, frames and external connections. Decide which code is genuinely first-party and approved. Introduce escaping and safe component rendering for user and model content. Write a strict candidate CSP, using trusted nonces or hashes for appropriate assets, and test it in report-only mode.
Inspect violations in normal, mobile and accessibility workflows. Repair unsafe handlers, unreviewed dependencies and nonce mismatches. Then enable enforcement in stages and confirm that critical school functions still work. Maintain a rollback plan that does not require reverting to unrestricted execution. A new trusted script must pass code review, not automatically receive approval from an AI generator.
19. Negative tests for AI previews
Create a fictional lesson plan containing literal JavaScript examples and verify the page displays them as text without execution. Test a Markdown link to an unapproved host, an event-handler-looking attribute, an iframe with unapproved scripts and a malicious-looking HTML block. The application should process each under its documented rendering policy.
Test nonce freshness across cached pages, policy and script-attribute matching, Report-Only telemetry, and a browser that lacks optional Trusted Types enforcement. A defensible report names what each layer actually blocked. Do not call the site secure from one green CSP header in a response.
20. What CSP cannot tell an agent
A CSP violation cannot prove a student’s homework is plagiarized, a tutorial is correct or a file was published. It concerns browser content and execution policy. An AI assistant must not translate one technical protection into sweeping assurance about the trustworthiness of everything on the page.
After a user approves a consequential action such as publishing an article, the application still needs the proper authenticated API call and destination receipt. The presence of a strict CSP merely reduces particular browser risks. Authorization and verified completion live at separate system boundaries.
21. Six review questions and answers
Question one: is a CSP nonce a reusable site-wide password? No; generate it unpredictably for the relevant response. Question two: does Report-Only block violations? No. Question three: should arbitrary model HTML receive a trusted nonce? No. Question four: does CSP replace safe escaping? No.
Question five: can a browser report a violation caused by legitimate older code? Yes. Question six: does a script hash authorize any other code with a similar name? No; it concerns the actual content under the applicable hash rules. The recurring theme is that technical controls should be narrowly scoped, measurable and layered.
22. Frequently asked questions
What is CSP? A browser-enforced Content Security Policy conveyed through HTTP headers or supported markup. What is a nonce? A per-response unpredictable value used to allow selected scripts or styles. What is Report-Only? A mode for observing prospective violations without enforcing that policy.
Does strict-dynamic make arbitrary scripts safe? No. Are Trusted Types a sanitizer by themselves? No; the transformation policy must be correct. Does CSP stop prompt injection into AI instructions? Not on its own. Does the article claim existing ASI? No, it discusses web defenses for present-day systems.
23. Authoritative sources and reading routes
Read MDN: Content-Security-Policy for directive and nonce semantics, and MDN: CSP practical implementation for strict policies, hashes and report-only rollout. Consult official browser documentation for Trusted Types and sandbox behavior before deploying new controls.
For related eduKateSG guidance, visit Agent Markdown Rendering, Cross-Origin Messaging and CORS Decisions. Browse the main How Super Intelligence Works collection. Keep executable trust separate from generated educational content.