Review Vue 3 server-side-rendered entry points, module-scope state, and template bindings for the two SSR-specific defect classes Vue's own documentation calls out directly: cross-request state pollution from state that is not created fresh per request, and injection through unsanitized v-html or unvalidated dynamic :href/:src bindings — without re-litigating composable/reactivity architecture, hydration-mismatch mechanics, or general component design in every response. This skill exists so the review stays anchored to the two documented, security-critical defect classes instead of drifting into a general \"SSR code review.\"
Use this skill when the user asks to:
\nentry-server.js/.ts, or equivalent request-handling code that creates the Vue app for rendering),v-html usage is safe,Do not use this skill for:
\nvue-composition-api-architecture-review instead,resolve-library-id (matched result: /vuejs/vue) before citing any SSR-mechanism or v-html-behavior claim./vuejs/vue is Vue's core source-and-test repository (its SSR test fixtures and server-renderer package source cover Vue 2's vue-server-renderer), not the Vue 3 prose docs site. Use query-docs against it only to corroborate low-level rendering mechanics (e.g., that v-html compiles directly to setting the innerHTML DOM property with no sanitization step). It does not reliably surface the Vue 3 SSR guide's per-request-instance narrative or the Security guide's v-html/dynamic-binding rules — for that guidance, use the official_docs URLs in this skill's metadata.json and label the claim documentation-based.package.json first to confirm which Vue major and SSR toolchain are in use (vue-server-renderer for Vue 2, @vue/server-renderer / a meta-framework like Nuxt for Vue 3) — the per-request app/store creation requirement and the exact API names differ by major version and toolchain; do not apply Vue 3 API names to a Vue 2 codebase or vice versa.official_docs URLs in this skill's metadata.json and label the claim documentation-based, unverified against current release.v-html sanitizer gap to MEDIUM just because it has not been observed exploited yet — the risk is in the structure, not in whether someone has already hit it.v-html binding whose data source includes any user-reachable input (route params, query strings, request bodies, third-party API responses that themselves echo user input) unless a named sanitizer call (e.g., DOMPurify) is visibly present on that exact data-flow path. A sanitizer import existing elsewhere in the codebase does not clear this bar — trace the specific path under review.:href/:src bindings for scheme validation (an allowlist rejecting javascript: and other non-http(s) schemes) whenever the bound value's source includes user-reachable input. An unvalidated dynamic URL binding fed by user input is a MEDIUM-to-HIGH finding depending on reachability from an authenticated or public surface.createApp()/createSSRApp() call per request) but still close over a shared module-level cache, singleton, or default parameter passed in from outer scope — the factory pattern alone does not guarantee isolation if it references mutable shared state from its enclosing scope.Load these only when needed:
\nv-html usage or a dynamic :href/:src binding. Includes the OWASP XSS grounding reference; load that citation only when a v-html finding is actually present.Return, at minimum:
\nstate-pollution, xss, or url-injection), the concrete data-flow trace (module-scope declaration and its reachability, or the origin-to-sink path for the injection), and a fix sketch matching Vue's documented pattern,v-html finding, an explicit statement of whether a sanitizer call is present on the traced path — never approve on the assumption one exists elsewhere,repo evidence, documentation-based, or inference), with structural risk findings explicitly labeled as structural risk, not as confirmed-exploited,