Content Security Policy and XSS Mitigation Blueprint
Formulate a strict Content Security Policy and browser runtime defense blueprint to eliminate client-side vulnerabilities.
Use this template when hardening modern web applications against cross-site scripting (XSS), data exfiltration, and supply chain script attacks. It produces an implementation-ready CSP rollout plan tailored to complex third-party dependencies.
Role: Lead Application Security Engineer specializing in browser runtime defense and web client hardening.
Context
- Target web platform: {{app_name}}
- Active security headers: {{current_csp_header}}
- Third-party SaaS widgets and CDNs: {{external_integrations}}
- Legacy script execution patterns: {{inline_script_dependencies}}
- Session and credential handling: {{auth_mechanism}}
- Recent audit and scanner alerts: {{vulnerability_findings}}
Task
Deliver an enterprise browser security hardening report that outlines a strict Content Security Policy (CSP Level 3) migration path, eliminates cross-site scripting attack vectors, and strengthens client-side execution boundaries.
Method
- Analyze {{vulnerability_findings}} to classify active DOM-based, stored, and reflected XSS exposures in {{app_name}}.
- Audit {{current_csp_header}} for unsafe directives such as unsafe-inline, unsafe-eval, or overly broad wildcard hosts.
- Map {{inline_script_dependencies}} to determine nonce-based or hash-based refactoring requirements.
- Catalog domains and resource types utilized by {{external_integrations}} to establish strict connect-src, script-src, and frame-src whitelists.
- Review {{auth_mechanism}} to verify token isolation, cookie attributes (HttpOnly, SameSite, Secure), and storage risks.
- Construct a CSP transition plan using Report-Only mode to discover breaking changes safely.
- Formulate violation telemetry aggregation pipelines to capture and triage blocked requests.
- Establish automated header linting and security regression checks within the existing CI/CD build pipeline.
Constraints
- MUST NOT allow 'unsafe-inline' or 'unsafe-eval' in the final proposed enforcement policy.
- MUST account for all valid vendor endpoints identified in {{external_integrations}}.
- Remediation steps for {{inline_script_dependencies}} must maintain full application functionality.
- The report must provide exact, syntactically valid CSP header strings.
Output format
Produce a structured technical report containing:
- Executive Risk & Posture Evaluation (150 words)
- Threat Vector Diagnostic (table mapping {{vulnerability_findings}} to root causes and fixes)
- Staged CSP Migration Blueprint (Draft CSP-Report-Only string and Final Enforced CSP string)
- Inline Script & Dependency Modernization Guide (nonce integration and refactoring examples)
- Session Security & Cookie Hardening Directives (specific configurations for {{auth_mechanism}})
- CI/CD Pipeline Policy Guardrails (linter and build validation commands)
Self-review
- Does the target CSP eliminate unsafe-inline and unsafe-eval without breaking {{inline_script_dependencies}}?
- Are all origins in {{external_integrations}} accounted for in the policy directives?
- Does the report clearly differentiate Report-Only rollout from blocking enforcement?
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.