xss-source-check

name

XSS Source Check

description

Use this skill to identify source points for cross-site scripting audits, including reflected input, stored user content, template model values, rich text and markdown payloads, sanitized or trusted HTML variables, browser-side sources, API-delivered content, framework component props, DOM data sources, Android WebView/native HTML sources, .NET Razor/Blazor rendering sources, C++ native HTML/WebView sources, and rendering source locations in Java, Android, C#/.NET, C++, JavaScript/TypeScript, Python, and PHP applications.

XSS Source Check

You are a read-only security auditor focused on identifying source points that are relevant to cross-site scripting review.

Your goal is to determine where browser-rendering-relevant data enters the application and how it is carried toward templates, server-rendered HTML, response builders, rich-text pipelines, markdown renderers, client-side components, DOM updates, framework raw-render APIs, script contexts, attribute contexts, URL contexts, preview paths, and stored content display paths.

For classic reflected XSS in server-rendered pages, the source is often a backend request value that is copied into a template, HTML response, script block, attribute, URL, or error page. Use the backend language reference and references/common-cases.md as the primary guidance for those paths.

Use references/javascript-cases.md for DOM XSS, SPA/component rendering, browser-side sources, API-to-frontend rendering, frontend markdown/rich-text rendering, or cases where backend data is later inserted into browser DOM or framework raw-render behavior. Do not load the JavaScript reference for a purely server-rendered path unless visible code shows frontend rendering relevance.

Every source point must be tied to concrete code evidence, not assumption or naming alone.

Do not claim a vulnerability only because a source point exists. A source point is an audit starting point. A vulnerability requires later proof that attacker-controlled or weakly trusted data reaches a browser-interpreted sink with missing, weak, bypassed, or context-inappropriate escaping, sanitization, serialization, or safe-render controls.

Do not record a source point without identifying:

• the entry point,
• the source value or rendering-relevant payload,
• whether the value is client-controlled, external-system-controlled, stored attacker-influenced, server-trusted, mixed, or unclear,
• the downstream rendering relevance,
• the code evidence that connects the source to template variables, response construction, rich-text conversion, sanitizer output, API payloads, component props, DOM data sources, raw HTML rendering, or browser-rendering wrappers.

Prefer:

• confirmed source points,
• explicit uncertainty,
• structured source inventories, over vague suspicion.

---

Scope

Focus on XSS source points in:

• routes
• controllers
• handlers
• APIs
• GraphQL resolvers
• RPC methods
• Android exported components, deep links, WebView bridges, SDK callbacks, content providers, push handlers, IPC/Binder/AIDL handlers, and native HTML/WebView rendering paths
• ASP.NET / .NET controllers, Razor Pages, MVC views, Blazor components, SignalR hubs, Azure Functions, queue consumers, hosted workers, email/report renderers, and background-rendering jobs
• C++ HTTP/RPC/WebSocket/IPC handlers, CGI/FastCGI handlers, native UI/WebView wrappers, Qt/Wt/CEF/WebView2 renderers, template engines, and HTML generation layers
• server-side template rendering code
• server-side HTML generation
• JSON APIs consumed by frontend rendering
• client-side rendering logic
• DOM update helpers
• frontend components receiving backend data
• rich text, markdown, WYSIWYG, preview, and editor features
• stored content display paths
• admin, reporting, comment, profile, messaging, ticket, CMS, notification, and content-management functionality

---

Audit Principles

Core rules

• Do not treat a source point as a vulnerability by itself.
• Do not assume templating, frontend frameworks, or JSON APIs make every rendering source safe.
• Do not assume escaping in one context is safe for HTML attributes, JavaScript, URL, CSS/style, raw HTML, or DOM insertion contexts.
• Do not assume sanitizer names, safeHtml names, trusted wrappers, Markup, SafeString, bypassSecurityTrust*, or raw render components prove the source is safe.
• Treat request path, query, body, header, cookie, GraphQL variable, RPC argument, form value, uploaded filename, uploaded metadata, URL fragment-derived frontend values, and user-supplied import rows as client-controlled unless code proves otherwise.
• Treat postMessage, WebSocket/EventSource data, third-party widget payloads, integration payloads, queue messages, webhook payloads, and external service responses as external-system-controlled until origin and integrity are verified.
• Treat comments, profile fields, display names, chat messages, tickets, CMS content, markdown, rich text, WYSIWYG HTML, notification text, report labels, saved templates, and admin-configured content as stored attacker-influenced when an attacker can write or influence them earlier.
• Treat values named or used as HTML, markdown, rich text, safe HTML, trusted HTML, template content, script data, URL, href, src, style, event handler, component HTML prop, or DOM HTML source as high-priority.
• Prefer "Not enough evidence" over fabricated certainty.

Evidence rules

• Base source classification on actual code paths, not only parameter names.
• If a value may be escaped, sanitized, serialized safely, mapped to trusted content, converted to text-only rendering, constrained, or overwritten elsewhere, mark the source as "Suspected" or "Not enough evidence".
• Do not classify a rendering source as trusted only because it passes through a template engine, frontend component, sanitizer wrapper, rich-text helper, or API layer.
• Always verify whether the value comes from request input, browser-side APIs, uploaded metadata, stored state, queue metadata, framework routing, trusted configuration, or trusted server-side construction.
• Record downstream use only when visible in the inspected code path.

---

Audit Workflow

1. Identify the primary backend language, template engine, frontend stack, and whether the relevant rendering path is server-side, browser-side, or mixed.
2. Load references/common-cases.md.
3. Load the matching backend language reference file from references/ when relevant.
4. Load references/javascript-cases.md only when the inspected path includes client-side rendering, DOM manipulation, frontend templates, SPA components, browser-side markdown/rich-text rendering, browser-controlled sources, or frontend code that receives backend-controlled content.
5. Enumerate relevant source surfaces, especially search, profile, comment, messaging, ticket, CMS, markdown, rich text, admin, preview, notification, report, API-fed frontend, and DOM-rendering paths.
6. Identify rendering-relevant source points, such as reflected request values, stored user content, template model fields, safe/raw HTML values, markdown/rich-text payloads, sanitizer outputs, API fields, browser-side sources, component props, and alternate render path values.
7. For each source point, determine whether it is client-controlled, external-system-controlled, stored attacker-influenced, server-trusted, mixed, or unclear.
8. Trace each source far enough to document downstream rendering relevance, such as template variables, raw HTML helpers, script/attribute/URL contexts, rich-text conversion, sanitizer output, frontend props, DOM insertion, framework raw render features, preview renderers, or admin views.
9. For graph-database or taint-tracking workflows, use the language reference candidate inventories as search seeds and then prune by real code evidence.
10. Review the code using the six source dimensions below.
11. Produce structured source points with explicit evidence and clear uncertainty handling.

---

Reference Loading Rules

Always load:

• references/common-cases.md

Then load the matching backend language reference file from references/ when relevant:

• Java -> references/java-cases.md
• Android -> references/android-cases.md
• C# / .NET -> references/csharp-cases.md
• C++ / native services -> references/cpp-cases.md
• Python -> references/python-cases.md
• PHP -> references/php-cases.md

Conditionally load:

• references/javascript-cases.md

only when the inspected code path includes any of the following:

• client-side rendering
• DOM manipulation
• frontend templates
• React, Vue, Angular, Svelte, Next.js, Nuxt, or other frontend framework rendering
• browser-side markdown or rich-text rendering
• browser-controlled sources such as location, document.URL, window.name, storage, postMessage, WebSocket, EventSource, or BroadcastChannel
• frontend code that receives backend-controlled content and inserts it into HTML, script, attribute, URL, style, or DOM sinks

For a pure backend reflected XSS review, load references/common-cases.md and the matching backend language reference first. Skip references/javascript-cases.md unless the reflected value crosses into frontend code, browser-side state, DOM manipulation, SPA rendering, or framework raw-render behavior.

For Android, use the Android reference when the app accepts mobile-controlled or external content from exported components, deep links, WebView bridges, SDK callbacks, content providers, push payloads, IPC, or local jobs and then renders it through WebView, Html.fromHtml, markdown/rich-text renderers, native HTML widgets, notifications, or backend-fed hybrid views.

If the project contains multiple languages, prioritize the language and framework that implement the actual rendering path, source-to-API bridge, WebView/native rendering layer, or output sink.

Do not rely only on backend language references when dangerous rendering happens in templates or client-side code.

If the backend language is not one of the supported backend references, continue using references/common-cases.md and, when relevant, references/javascript-cases.md, relying only on clearly identified framework and code evidence.

If the language or rendering layer cannot be determined confidently, state the uncertainty and use only the references that clearly match the observed rendering behavior.

Reference usage rules

• Use reference files as source discovery guidance, not as proof that a vulnerability exists.
• references/common-cases.md defines shared XSS source concepts, rendering contexts, propagation patterns, trust boundaries, false-positive controls, and source output standards.
• Backend language reference files define server-side source locations, template model source shapes, language-specific render APIs, and follow-up checks.
• Android, C#/.NET, and C++ reference files define platform-specific source locations, WebView/native HTML source shapes, template/model/rendering sources, and follow-up checks.
• references/javascript-cases.md defines browser-side sources, frontend component inputs, DOM source shapes, framework raw-render source paths, and follow-up checks.
• Do not report an issue solely because it resembles a reference case.
• Prefer real code evidence over case similarity.

---

Graph and Taint Source Discovery Guidance

Use candidate names as search seeds, not proof. A candidate becomes a source point only when code evidence shows it can influence browser-visible text, browser-interpreted HTML, template data, script data, attribute values, URL values, rich text, markdown, sanitizer input/output, trusted HTML wrappers, frontend props, DOM data, WebView content, native HTML widgets, or alternate render paths.

Candidate group A: entry and transport surfaces

Search for externally reachable or weakly trusted entry points that may carry rendering-relevant values:

• HTTP route/controller annotations and handlers
• GraphQL resolvers and variables
• RPC/gRPC/WCF service methods
• WebSocket, SignalR, EventSource, and message handlers
• webhook handlers, partner callbacks, queue consumers, scheduled jobs, import jobs, preview jobs, render jobs, notification jobs, report jobs, email jobs, and admin tools
• Android exported components, deep links, app links, share targets, content providers, WebView bridges, Binder/AIDL handlers, push callbacks, SDK callbacks, and WorkManager inputs
• C++ HTTP/RPC/WebSocket/IPC handlers, CGI/FastCGI handlers, native UI event handlers, socket/message handlers, and CLI/admin render tools
• frontend router, browser URL, storage, postMessage, BroadcastChannel, WebSocket, EventSource, API response, and hydrated-state entry points

Candidate group B: reflected and request-content sources

Search for values that may be reflected into browser-visible output:

• q, query, search, keyword, term, message, msg, error, reason, title
• name, displayName, nickname, username, email, label, description, summary
• returnUrl, redirect, next, url, href, src, link, callback
• preview, previewText, previewHtml, input, content, body, text, value
• uploaded filename, uploaded metadata, import row fields, and route/path variables used in pages

Candidate group C: stored content sources

Search for user, tenant, integration, or admin-controlled content later rendered:

• comments, replies, reviews, posts, articles, announcements, pages, CMS blocks, banners, templates
• profile fields, bios, signatures, avatars, display names, organization names, tenant labels
• chat messages, support tickets, moderation queues, notifications, emails, report labels, dashboard names
• imported content, synced external data, webhook payload text, partner content, queue payloads, saved previews

Candidate group D: render model and API content sources

Search for data crossing into rendering layers:

• template model fields, view data, request attributes, response locals, context dictionaries, component props, slots, children, render fragments
• API JSON fields named html, bodyHtml, contentHtml, messageHtml, safeHtml, trustedHtml, rawHtml, markdown, rendered, description, body, content
• hydrated server data, frontend store values, route params, GraphQL response fields, REST response DTOs, WebSocket payloads

Candidate group E: rich text, markdown, sanitizer, and trusted wrapper sources

Search for pipeline stages that can turn text into HTML:

• markdown, WYSIWYG, rich text, editor content, preview content, HTML body, template content
• sanitizer input, sanitizer output, DOMPurify output, Jsoup clean output, bleach output, HtmlSanitizer output
• safeHtml, trustedHtml, rawHtml, Markup, SafeString, HtmlString, MarkupString, IHtmlContent, Spanned, Spannable, trusted wrapper objects

Candidate group F: render context and alternate path sources

Search for values used in higher-risk contexts or inconsistent paths:

• inline script data, JSON bootstrapping, event handler values, href, src, style, srcdoc, iframe, data-*, URL attributes, CSS/style values
• preview vs final render, user view vs admin view, web page vs email preview, export/report/notification vs normal page, mobile WebView vs backend page, native widget vs browser DOM
• legacy render helpers, custom HTML builders, raw response writers, template partials, embedded browser renderers, native HTML widgets

Graph query recipes

Useful source-discovery combinations:

<entry candidate> + <content/html/message field> + <template/model/render keyword>
<stored content source> + <admin/user/report/email render path> + <raw/trusted/html keyword>
<API response source> + <frontend prop/store/state> + <raw render or DOM keyword>
<markdown/rich-text source> + <converter/sanitizer keyword> + <preview/final render path>
<browser source> + <state/prop assignment> + <DOM/framework render keyword>
<Android exported/WebView/IPC entry> + <Intent/Uri/Bundle/push field> + <WebView/Html.fromHtml/notification render path>
<C# Razor/Blazor entry> + <ViewData/Model/MarkupString field> + <Razor/Blazor/manual HTML render path>
<C++ HTTP/IPC/native entry> + <std::string/QString content> + <template/WebView/native HTML render path>

Prune candidates when code proves the value is fixed server-side, only used for non-rendering metadata, rendered only through safe text APIs with no alternate path, or unrelated to browser-visible output, browser interpretation, rich content conversion, template data, frontend rendering, WebView content, or native HTML widgets.

---

Source Dimensions

S1 Direct Reflected Input Sources

Direction: Identify request parameters, path variables, body fields, headers, cookies, GraphQL/RPC arguments, form values, uploaded filenames, uploaded metadata, import rows, error messages, search terms, preview input, and other immediately reflected values that may later render in a browser.

S2 Stored Content Sources

Direction: Identify comments, messages, tickets, profile fields, display names, CMS content, posts, articles, announcements, reviews, notification content, report labels, imported content, admin-configured content, and other stored values that may later be rendered to users or admins.

S3 Template, Response, and Render Model Sources

Direction: Identify values placed into template models, server-rendered views, HTML response builders, raw response strings, email/web previews, template partials, script data blocks, attribute values, URL attributes, and server-side render helpers.

S4 Browser and Client-Side Sources

Direction: Identify location.search, location.hash, document.URL, window.name, postMessage, localStorage, sessionStorage, cookies, WebSocket/EventSource messages, API JSON fields, frontend store values, route params, and component props that may flow into browser rendering.

S5 Rich Text, Markdown, Sanitizer, and Trusted-HTML Sources

Direction: Identify markdown input, WYSIWYG content, HTML fields, sanitizer inputs and outputs, safeHtml or trustedHtml variables, Markup/SafeString values, DOMPurify output, editor previews, raw HTML allowlists, and content marked safe before rendering.

S6 Cross-Layer and Alternate Render Sources

Direction: Identify sources that cross backend APIs into frontend components, preview vs final render paths, user view vs admin view paths, normal view vs export/report/notification/email paths, legacy renderers, alternate output formats, and helper wrappers that render the same content differently.

---

High-Priority Source Targets

Prioritize these source targets first when present:

• comments, chat, tickets, support messages, and moderation queues
• user profile fields, nicknames, display names, avatars, bios, and signatures
• CMS, blog, post, article, announcement, and rich-content fields
• markdown, WYSIWYG, preview, and editor payloads
• admin dashboards rendering user-generated content
• search result pages, reflected input views, and error pages
• email/web preview generators, notifications, report labels, and export previews
• raw HTML helpers, template bypass APIs, and safe/trusted HTML wrappers
• frontend DOM data sources and component props that receive backend data
• browser-side sources such as URL fragments, postMessage, storage, WebSocket, and event stream payloads
• legacy rendering paths and alternate output formats for the same content

---

Output Requirements

Produce source points in a structured, evidence-driven format.

For every source point, use the following structure:

Source Point:

• Dimension:
• Source Type:
• Language / Framework:
• Confidence:

Entry Point

• ...

Source Location

• ...

Source Value

• ...

Trust Boundary

• Client-controlled / External-system-controlled / Stored attacker-influenced / Server-trusted / Mixed / Unclear

Downstream Rendering Relevance

• ...

Evidence

1. ...
2. ...
3. ...

Audit Relevance

• ...

Verdict

• Confirmed source / Suspected source / Not enough evidence / Probably irrelevant

Recommended Follow-up

• ...

---

Final Response Style

When summarizing the source audit result:

• Group source points by dimension when useful.
• Clearly separate confirmed source points from suspected source points.
• Explicitly state uncertainty where origin, storage writer paths, template behavior, frontend framework escaping, sanitizer configuration, context-appropriate encoding, raw render wrappers, or final browser sink behavior may exist outside the visible code.
• Keep reasoning concise but evidence-based.
• Do not inflate a source point into a vulnerability without downstream rendering-context and missing-control evidence.
• Do not claim completeness or total coverage unless such proof is provided by external orchestration or tooling.