Web
AuraScore 81/100

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.

Template

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

  1. Analyze {{vulnerability_findings}} to classify active DOM-based, stored, and reflected XSS exposures in {{app_name}}.
  2. Audit {{current_csp_header}} for unsafe directives such as unsafe-inline, unsafe-eval, or overly broad wildcard hosts.
  3. Map {{inline_script_dependencies}} to determine nonce-based or hash-based refactoring requirements.
  4. Catalog domains and resource types utilized by {{external_integrations}} to establish strict connect-src, script-src, and frame-src whitelists.
  5. Review {{auth_mechanism}} to verify token isolation, cookie attributes (HttpOnly, SameSite, Secure), and storage risks.
  6. Construct a CSP transition plan using Report-Only mode to discover breaking changes safely.
  7. Formulate violation telemetry aggregation pipelines to capture and triage blocked requests.
  8. 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:

  1. Executive Risk & Posture Evaluation (150 words)
  2. Threat Vector Diagnostic (table mapping {{vulnerability_findings}} to root causes and fixes)
  3. Staged CSP Migration Blueprint (Draft CSP-Report-Only string and Final Enforced CSP string)
  4. Inline Script & Dependency Modernization Guide (nonce integration and refactoring examples)
  5. Session Security & Cookie Hardening Directives (specific configurations for {{auth_mechanism}})
  6. 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?
AuraScore breakdown
81/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 engineering12/12 · Strong

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 efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

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
security
csp
xss