Cross-Site Scripting Sink Analysis Prompt

This prompt is designed for security engineers and DevSecOps pipelines that need to perform a deep, structured analysis of a specific code snippet to determine if user-controlled data reaches a dangerous browser sink without adequate output encoding. The core job-to-be-done is not broad vulnerability scanning; it is a focused, evidence-backed trace of a single suspected Cross-Site Scripting (XSS) vector. The ideal user is a security reviewer who has already identified a potential source of user input—such as a URLSearchParams getter, a postMessage listener, or a server-rendered template variable—and needs to rigorously map its flow through JavaScript functions, DOM manipulations, or template expressions to a known dangerous sink like innerHTML, eval, or document.write.

To use this prompt effectively, you must provide a complete and self-contained code snippet as the [CODE_SNIPPET] input. The prompt assumes you have already isolated the suspicious code path; it will not scan a large codebase for vulnerabilities. You should also specify the [SOURCE] (the exact user-controlled input point) and the [SINK] (the suspected dangerous function or property) to focus the analysis. The prompt requires you to define an [OUTPUT_SCHEMA] that structures the response into a machine-readable format, typically JSON, with fields for the data flow trace, encoding assessment, CSP evaluation, and a final exploitability verdict. This structured output is critical for integrating the analysis into automated CI/CD security gates or vulnerability management systems.

Do not use this prompt as a general-purpose code reviewer, a substitute for dynamic analysis with a browser, or a comprehensive SAST tool. It is ineffective for analyzing highly obfuscated or minified code without deobfuscation, and it cannot reason about client-side JavaScript that is dynamically constructed on the server. The prompt's value is in its structured reasoning about encoding contexts and CSP bypasses, not in discovering new sinks. After running the analysis, you must validate its findings with a manual review or a dynamic test, as the model may hallucinate data flows in complex, callback-heavy asynchronous code. The next step is to take the structured finding and feed it into your vulnerability management workflow for tracking and remediation.

This prompt template is designed to be pasted directly into your AI tool of choice. It instructs the model to act as a security engineer performing a focused Cross-Site Scripting (XSS) sink analysis. The core job is to trace a suspected data flow from a user-controlled source to a potentially dangerous browser sink, assess the adequacy of any output encoding, and determine the real-world exploitability. Replace the bracketed placeholders with the specific code snippet, the identified source, the identified sink, and your application's Content Security Policy (CSP) before running the analysis.

markdownCopy
You are a senior application security engineer specializing in client-side web security and Cross-Site Scripting (XSS) analysis. Your task is to perform a rigorous sink analysis on the provided code.

**INPUT CONTEXT**
- **Code Snippet:**
```[LANGUAGE]
[CODE_SNIPPET]

• Identified Source: [USER_CONTROLLED_SOURCE, e.g., window.location.hash, document.referrer, a specific API response field]
• Identified Sink: [DANGEROUS_BROWSER_SINK, e.g., element.innerHTML, eval(), document.write(), a jQuery html() call]
• Active Content Security Policy (CSP): [CSP_HEADER_VALUE or 'No CSP is present']

ANALYSIS CONSTRAINTS

• Trace the complete data flow from the identified source to the identified sink.
• Determine the XSS context: HTML context, attribute context, JavaScript context, or URL context.
• Assess whether any output encoding, sanitization, or transformation is applied to the data before it reaches the sink. State explicitly if it is missing, inadequate for the context, or correctly implemented.
• Evaluate the exploitability of this specific data flow. If it is not exploitable, explain the precise mitigating factor (e.g., a strong sanitizer, a browser API restriction).
• Analyze the provided CSP to determine if it would mitigate a successful injection. State if the CSP can be bypassed.
• Classify the XSS type as DOM-based, Reflected, or Stored based on the source and data flow.

OUTPUT SCHEMA You must produce a JSON object with the following structure. Do not include any text outside the JSON block. { "finding_id": "string, a unique identifier for this finding", "xss_type": "string, one of: 'DOM-based', 'Reflected', 'Stored'", "source": "string, the confirmed user-controlled source", "sink": "string, the confirmed dangerous sink", "data_flow_summary": "string, a step-by-step trace of the data from source to sink", "context": "string, one of: 'HTML', 'Attribute', 'JavaScript', 'URL'", "encoding_assessment": { "is_present": "boolean", "method": "string or null, e.g., 'HTML entity encoding', 'JS string escaping'", "is_adequate": "boolean or null, is the encoding sufficient to prevent XSS in this context?" }, "exploitability": { "is_exploitable": "boolean", "reasoning": "string, a clear explanation of why it is or is not exploitable" }, "csp_mitigation_assessment": { "would_mitigate": "boolean", "reasoning": "string, explain if the CSP would stop the injection and if there are bypasses" }, "remediation": "string, a concrete, context-appropriate fix (e.g., 'Use textContent instead of innerHTML', 'Apply JS string escaping before passing to eval')", "confidence": "string, one of: 'high', 'medium', 'low'" }

To adapt this prompt, start by replacing the placeholders in the INPUT CONTEXT section. The [CODE_SNIPPET] should be a focused block of code, not an entire file, to keep the analysis sharp. The [USER_CONTROLLED_SOURCE] and [DANGEROUS_BROWSER_SINK] are your starting hypotheses; the model's job is to confirm and trace the path between them. The [CSP_HEADER_VALUE] is critical for a realistic assessment—if you don't provide it, the model cannot evaluate the defense-in-depth layer. For high-risk applications, always follow this automated analysis with a manual penetration test to confirm the finding and rule out bypasses the model may have missed.

Integrating this prompt into an application requires treating it as a deterministic analysis step within a larger security review pipeline. The prompt is designed to be called programmatically, receiving a structured input payload containing the code snippet, identified sources, and identified sinks. The calling application—whether a CI/CD plugin, a custom security bot, or a manual review CLI tool—is responsible for assembling this context before invoking the model. The model's response must be parsed as structured JSON and validated against a strict schema before any downstream action, such as posting a finding to a security dashboard or blocking a pull request, is taken.

The implementation should follow a validate-retry-escalate pattern. First, parse the model's JSON output and validate it against the expected schema (fields like data_flow_path, output_encoding_assessment, csp_mitigation_analysis, and final_risk must be present and correctly typed). If validation fails, implement a single retry with a repair prompt that includes the raw output and the specific schema violation errors. If the retry also fails, the finding should be flagged for mandatory human review rather than silently dropped. For high-risk code paths (e.g., authentication flows, payment processing), consider always requiring human approval for final_risk ratings of high or critical, regardless of model confidence. Log every request, response, and validation result to an immutable audit trail to support post-review analysis and model performance evaluation over time.

When choosing a model, prefer those with strong code reasoning capabilities and reliable JSON mode. The prompt is structured to work with tool-calling APIs by defining the output schema as a function, which is the most reliable way to enforce structured output. Avoid using this prompt with small, general-purpose models that may hallucinate data flow paths or misclassify encoding contexts. For runtime efficiency in CI/CD, cache the system prompt and consider batching multiple sink analyses for a single file into one request to reduce latency. Do not use this prompt's output as the sole gate for a production deployment; it is an expert triage assistant that accelerates human review, not a replacement for penetration testing or runtime protection mechanisms like strict Content Security Policies.