Web
AuraScore 83/100

Strict Content Security Policy and DOM XSS Defense Spec

Develop a CSP Level 3, Trusted Types, and script execution lockdown specification for modern single-page apps.

Use this template when securing a web application against Cross-Site Scripting (XSS), data exfiltration, and supply chain script tampering through browser-enforced headers.

Template

Role: Senior Web Application Security Engineer specializing in browser-side exploit mitigation.

Context

  • Primary App Domain: {{app_domain}}
  • Approved Third-Party Scripts: {{third_party_scripts}}
  • Security Violation Endpoint: {{csp_reporting_endpoint}}
  • Trusted Types Policy Name: {{trusted_types_policy_name}}
  • Inline Styling Strategy: {{inline_style_strategy}}
  • Nonce Delivery Architecture: {{nonce_distribution_mechanism}}

Task

Author a comprehensive Content Security Policy (CSP Level 3) and Trusted Types enforcement specification that secures {{app_domain}} against script injection and unauthorized resource loading without breaking dynamic application rendering.

Method

  1. Audit all script execution vectors, formulating strict directives for script-src including nonces via {{nonce_distribution_mechanism}}.
  2. Define domain whitelisting and hash pinning rules for all items listed in {{third_party_scripts}}.
  3. Configure Trusted Types policies under {{trusted_types_policy_name}} to sanitize innerHTML, outerHTML, and script creation sinks.
  4. Design the handling of dynamic styles matching the requirement for {{inline_style_strategy}} while restricting unsafe-inline.
  5. Construct directive sets for connect-src, worker-src, frame-ancestors, object-src, and form-action.
  6. Formulate the violation payload ingestion schema and rate-limiting policy for {{csp_reporting_endpoint}}.
  7. Detail a 3-phase rollout roadmap: Report-Only Monitoring, Incremental Enforcement, and Strict Lock-down.

Constraints

  • MUST NOT use 'unsafe-inline' or 'unsafe-eval' in the final production enforcement policy for script-src.
  • MUST format the raw CSP HTTP header string ready for web server deployment.
  • MUST provide code examples for the JavaScript Trusted Types policy definition.
  • Keep policy definitions compliant with W3C CSP Level 3 standards.

Output format

    1. Complete HTTP Security Header Directive Map
    1. Production CSP Header String (One-line deployable format)
    1. Trusted Types Policy Implementation Specification
    1. Violation Telemetry & Alerting Pipeline Definition
    1. Phased Rollout & Fallback Operational Matrix

Self-review

  • Does the header block bypass vectors like object-src 'none' and base-uri 'self'?
  • Are all third-party integrations explicitly accounted for without overly broad wildcard origins?
  • Is the Trusted Types policy implementation resilient against DOM clobbering?
AuraScore breakdown
83/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering10/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency7/10 · Adequate

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness5/5 · Strong

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-web
technology-software
web-security
csp
trusted-types