DOM XSS and CSP misconfiguration remain the dominant client-side attack surface (OWASP A03: Injection and A05: Security Misconfiguration). Most reviews stop at grep-for-innerHTML or \"a CSP header exists, ship it.\" Neither proves anything: a sink match without confirmed taint is noise, and a CSP header with unsafe-inline, a wildcard script-src, or a permissive Trusted Types default policy provides false confidence while remaining fully bypassable. This skill exists so the review stays anchored to confirmed source-to-sink taint flow and directive-level CSP/Trusted Types analysis instead of drifting into either a shallow pattern-match report or a full framework-architecture review.
Use this skill when the user asks to:
\ninnerHTML, outerHTML, dangerouslySetInnerHTML, v-html, document.write/document.writeln, eval, Function(), or setTimeout/setInterval called with a string argument,<meta> tag,Content-Security-Policy: require-trusted-types-for 'script', trusted-types directive, or a TrustedTypePolicyFactory.createPolicy call),<script src> origins, or subresource integrity for supply-chain/injection risk,postMessage-based injection report.Do not use this skill for:
\nresolve-library-id before citing any sink-specific or sanitizer-specific claim (React: /websites/react_dev_reference; Vue: /websites/vuejs_guide; Angular: /websites/angular_dev or /websites/angular_dev_guide).package.json first to confirm the actual framework and major version in use — sink APIs and sanitizer defaults changed across major versions (e.g., Angular's DomSanitizer.bypassSecurityTrust* methods, React's dangerouslySetInnerHTML contract, Vue's automatic template escaping vs. explicit v-html). Do not apply one framework's sink semantics to another framework's codebase.official_docs URLs in this skill's metadata.json (MDN CSP header reference, W3C Trusted Types spec) and label it documentation-based./websites/opentelemetry_io) has no built-in CSP-violation-report receiver or native report-to/report-uri ingestion pipeline as of the current docs — if a user asks how to observe CSP violations, state this gap explicitly (documentation-based, gap confirmed via Context7) rather than inventing an integration; a custom collector endpoint receiving the browser's native CSP report POST is the documented pattern, not an OpenTelemetry-specific feature.official_docs URLs in this skill's metadata.json and label the claim documentation-based, unverified against current release.postMessage, localStorage/sessionStorage written by another origin or execution context, document.referrer, window.name) before flagging it as a blocker. A sink match with no confirmed taint path is a lower-severity pattern-only observation, not a finding — state the distinction explicitly in every response.unsafe-inline, unsafe-eval, a missing object-src 'none', a missing base-uri, a wildcard or overly broad script-src (e.g., https: alone, *), and strict-dynamic combined with a static nonce/hash misconfiguration that defeats its purpose.createHTML/createScript/createScriptURL callback returns the input unmodified (a permissive pass-through) defeats the enforcement even though trustedTypes.createPolicy('default', ...) is present in the code.package.json, not assumed from memory or from a different framework's conventions (React dangerouslySetInnerHTML, Angular DomSanitizer.bypassSecurityTrust*, Vue v-html/innerHTML render-function binding).postMessage event listener (window.addEventListener('message', ...)) for explicit event.origin validation before treating the handler as safe; an unchecked origin turns any cross-origin postMessage sender into an untraced taint source.<script src> targeting a third-party/CDN origin carries a paired integrity hash and crossorigin=\"anonymous\" attribute (Subresource Integrity); a <script> tag loading from an external origin with integrity absent is a confirmed supply-chain finding regardless of whether the origin is currently trustworthy. Also treat any dynamic script-injection path (document.createElement('script') followed by script.src = <value>) as needing the same scrutiny: if <value> derives from an untrusted/remote config (a tag-manager loader, analytics config endpoint, or any API response), confirm it is checked against an origin allowlist — ideally via a Trusted Types createScriptURL policy — before treating the injection path as safe, since SRI does not apply to dynamically assigned src values at all.Load these only when needed:
\ninnerHTML, dangerouslySetInnerHTML, v-html, document.write, eval-class API) and needs source-to-sink classification, grounded in the OWASP DOM-Based XSS Prevention Cheat Sheet.require-trusted-types-for enforcement mode, grounded in the W3C Trusted Types specification.<script src> inclusion, tag-manager/marketing-loader script injection, or a dynamic document.createElement('script') path fed by remote config, grounded in the MDN Subresource Integrity guide and the MDN CSP script-src reference.Return, at minimum:
\n<script src> or dynamic script-injection path in scope, an explicit SRI gap analysis (integrity/crossorigin present-and-matched, or absent and flagged) plus origin-allowlist status for any config-driven src value,repo evidence, documentation-based, or inference),