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.
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
- Audit all script execution vectors, formulating strict directives for script-src including nonces via {{nonce_distribution_mechanism}}.
- Define domain whitelisting and hash pinning rules for all items listed in {{third_party_scripts}}.
- Configure Trusted Types policies under {{trusted_types_policy_name}} to sanitize innerHTML, outerHTML, and script creation sinks.
- Design the handling of dynamic styles matching the requirement for {{inline_style_strategy}} while restricting unsafe-inline.
- Construct directive sets for connect-src, worker-src, frame-ancestors, object-src, and form-action.
- Formulate the violation payload ingestion schema and rate-limiting policy for {{csp_reporting_endpoint}}.
- 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
-
- Complete HTTP Security Header Directive Map
-
- Production CSP Header String (One-line deployable format)
-
- Trusted Types Policy Implementation Specification
-
- Violation Telemetry & Alerting Pipeline Definition
-
- 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?
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.