@raishin/vanguard-frontier-agentic 3.0.1 → 3.1.0

package/skills/frontend/vue-router-navigation-security-review/references/client-guards-and-control-flow.md

@@ -0,0 +1,188 @@
+# Client-Side Guards as an Authorization Boundary, and Navigation Control-Flow Risks
+
+Use this reference when the review scope includes a `router.beforeEach`/`beforeEnter` (or a
+meta-framework's route-middleware equivalent), any redirect returned from a guard, a catch-all
+route, or the app's `history` mode configuration. Covers rubric items 1, 5, 6, 7 (and their
+"not a finding" counterparts 8, 13, 14, 15).
+
+## What people get wrong
+
+The naive assumption:
+
+> "This route checks `isAuthenticated` in `beforeEach` and redirects to `/login` if it's false,
+> so the route is protected."
+
+Wrong in isolation. Vue Router's own guard mechanics confirm exactly what a guard is: a
+JavaScript callback that runs *in the browser*, before a navigation is allowed to resolve. It
+can return `false` to cancel the navigation, a route location to redirect, or (with the legacy
+third argument) call `next()` — all of this is client-side control flow (`repo evidence`,
+`/vuejs/router`, navigation-guards guide). None of it executes on a server the attacker doesn't
+control. A guard is the correct place for *UX* gating — don't render a protected page's shell
+to a user who hasn't logged in — but it is not, and cannot be, the mechanism that stops a
+request from reaching protected data, because:
+
+- the bundled JavaScript (and therefore the guard's logic) is fully visible and can be read,
+  patched via devtools, or skipped by calling the underlying API/data-fetch directly;
+- `isAuthenticated` itself is usually just client-held state (a token's presence, a decoded JWT
+  claim, a Pinia/Vuex flag) that the guard reads — it is not an independent judgment the server
+  makes on the attacker's actual request.
+
+## Officially grounded requirement
+
+Vue Router's documented guard pattern for authentication redirects is:
+
+```js
+router.beforeEach(async (to, from) => {
+  if (
+    !isAuthenticated &&
+    // Avoid an infinite redirect
+    to.name !== 'Login'
+  ) {
+    return { name: 'Login' }
+  }
+})
+```
+
+(`repo evidence`, `/vuejs/router`, navigation-guards guide — including the documented
+`to.name !== 'Login'` self-exclusion check, which is the framework's own prescribed loop-avoidance
+pattern, not an optional hardening step.) The docs also show the same pattern via `meta` fields:
+
+```js
+router.beforeEach((to, from) => {
+  if (to.meta.requiresAuth && !auth.isLoggedIn()) {
+    return { path: '/login', query: { redirect: to.fullPath } }
+  }
+})
+```
+
+(`repo evidence`, `/vuejs/router`, meta guide.) Nowhere in Vue Router's own documentation is a
+guard described as an authorization mechanism that replaces server-side access control — the
+docs frame it strictly as navigation control flow (cancel / redirect / proceed). The conclusion
+that a guard must not be the *sole* boundary is standard web-security practice (client-side
+controls are trivially bypassable; the server must independently authorize every request) rather
+than a Vue-Router-specific API claim — treat this specific conclusion as `inference` grounded in
+`documentation-based` general security guidance (OWASP: never rely on client-side enforcement
+alone), layered on top of the `repo evidence` fact that guards are browser-executed callbacks.
+
+Guards can also programmatically extend the route table and redirect in one motion:
+
+```js
+router.beforeEach(to => {
+  if (!hasNecessaryRoute(to)) {
+    router.addRoute(generateRoute(to))
+    return to.fullPath
+  }
+})
+```
+
+(`repo evidence`, `/vuejs/router`, dynamic-routing guide.) If `generateRoute()` builds a route
+pattern from untrusted input, the pattern itself becomes an injection surface — treat this the
+same as any other user-controlled routing input.
+
+## Non-negotiable design rules
+
+### 1. A guard finding requires evidence of an ABSENT server-side check, not just a present client check
+
+Do not flag "there is a client-side guard" as the defect. The finding is: this route's guard
+exists, **and** the review found no evidence that the API/data endpoint the route depends on
+independently checks authorization on the server. Look for: a 401/403 test or comment, a BFF
+layer, server middleware, or an API contract doc showing enforcement. If such evidence exists,
+the guard is correctly UX-only and this is not a finding (rubric item 8).
+
+### 2. Distinguish "guard exists with server enforcement" from "guard is believed to be enough"
+
+Ask explicitly, in the finding write-up, whether the codebase (or the user) asserts the guard
+*is* the security boundary ("the API trusts anyone who reached this route") versus treats it as
+UX convenience layered over real server checks. The former is the HIGH finding; the latter,
+with visible server-side evidence, is not.
+
+### 3. Redirect self-exclusion prevents the documented loop failure mode
+
+Every unconditional-redirect guard (`if (!isAuthenticated) return { name: 'Login' }` with no
+exclusion for the login route itself) is a HIGH finding: it produces an infinite redirect loop
+the moment the guard runs on the login route's own navigation. The fix is the framework's own
+documented pattern (`to.name !== 'Login'` or equivalent). A guard that already includes this
+check is correctly implemented (rubric item 13) — do not invent a residual risk without a
+concrete counter-path.
+
+### 4. A guard-returned or `next()`-passed redirect target must itself be traced
+
+If the redirect location returned by a guard (or passed to `next(...)`) is built from
+`to.query`/`to.params` rather than a hardcoded route, trace that value the same way you would
+trace an open-redirect target (see `open-redirect-and-injection.md`) — a guard can reintroduce
+the exact same open-redirect defect class it was written to prevent.
+
+### 5. Catch-all routes need their actual render path checked, not just their existence
+
+Vue Router's documented catch-all pattern is `{ path: '/:pathMatch(.*)*', name: 'NotFound',
+component: NotFound }` (`repo evidence`, `/vuejs/router`, dynamic-matching guide). This pattern
+alone is correct and not a finding. It becomes a finding only when: (a) the matched component
+renders `route.params.pathMatch` through an unsanitized sink, or (b) route table ordering
+causes the catch-all to shadow a route that should require authentication (read the full routes
+array in declaration order — Vue Router matches in the order routes are registered).
+
+### 6. History-mode server configuration is out of the router's control but in scope for the review
+
+`createWebHistory()` (`repo evidence`, `/vuejs/router`, history-mode guide) produces
+clean URLs but requires the server to serve the app's `index.html` for any path the SPA should
+handle client-side. This is not itself a router-code defect, but the review must check for
+evidence of the corresponding server/proxy fallback rule (nginx `try_files`, a framework's SPA
+middleware, a static-host rewrite rule) — its *absence* breaks direct links/refreshes, and an
+*overly broad* fallback (matching `/api/*` or asset paths that should 404 or route elsewhere)
+can leak information or serve the app shell where a different, more restrictive handler was
+intended.
+
+## Minimal safe pattern
+
+```js
+// Guard: UX-only redirect, with the documented loop-avoidance check.
+router.beforeEach((to, from) => {
+  if (to.meta.requiresAuth && !authStore.isAuthenticated && to.name !== 'Login') {
+    return { name: 'Login', query: { redirect: to.fullPath } }
+  }
+})
+
+// Server / BFF: the actual authorization boundary (illustrative — lives outside router code).
+// GET /api/account -> 401 if session invalid, regardless of any client-side navigation state.
+```
+
+Anti-pattern (guard as the only boundary — do not approve without server-side evidence):
+
+```js
+router.beforeEach((to, from) => {
+  if (to.meta.requiresAuth && !authStore.isAuthenticated) {
+    return { name: 'Login' } // no `to.name !== 'Login'` check -> loop risk
+  }
+  // No evidence anywhere in the reviewed diff/API that /api/account (or whatever
+  // this route fetches) independently checks the session server-side.
+})
+```
+
+## Adversarial checklist
+
+- If a user disables JavaScript, or calls the route's underlying API directly with curl/devtools,
+  does the server independently reject the unauthorized request? If unknown, ask — do not assume
+  yes.
+- Does every unconditional redirect-on-guard have a self-exclusion for its own target route?
+- Is any guard's redirect destination built from `to.query`/`to.params` rather than a hardcoded
+  name/path? If so, cross-reference `open-redirect-and-injection.md`.
+- Does `router.addRoute()` (if called from within a guard) build its route definition from any
+  user-reachable input?
+- Read the full `routes` array in registration order — does a catch-all or broad pattern appear
+  before a route that should take precedence and require auth?
+- Does `createWebHistory()` appear with no server config file in the reviewed diff/repo showing
+  the SPA-fallback rule? Flag this as an open question if the server config is out of scope
+  rather than assuming it is either correct or missing.
+
+## Verification targets
+
+- Grep for `router.beforeEach(`, `beforeEnter:`, and meta-framework middleware files
+  (`middleware/`, `definePageMeta`) and read each guard's full body.
+- Grep for `to.name !==`, `from.name !==`, or equivalent self-exclusion checks near a redirect
+  return/`next(...)` call inside each guard found above.
+- Grep for `router.addRoute(` calls inside guard bodies and trace the argument's construction.
+- Grep for `pathMatch(.*)` / `path: '*'` and read the matched component's template for any
+  `route.params.pathMatch` usage.
+- Grep for `createWebHistory(` and check the repo for a corresponding server config file
+  (`nginx.conf`, `vercel.json`, `netlify.toml`, a framework's server entry) with a fallback rule;
+  note explicitly if that file is outside the review's scope.

package/skills/frontend/vue-router-navigation-security-review/references/open-redirect-and-injection.md

@@ -0,0 +1,190 @@
+# Open Redirect, Scheme Injection, and Reflected XSS Through the Router
+
+Use this reference when the review scope includes a post-login redirect flow reading
+`route.query`, a dynamic `:to`/`:href` binding, or a `v-html`/`innerHTML` sink fed by
+`route.params`/`route.query`. Covers rubric items 2, 3, 4 (and their "not a finding"
+counterparts 9, 10, 11, 12).
+
+## What people get wrong
+
+The naive assumption, said three different ways depending on which defect it excuses:
+
+> "It's just redirecting back to where the user came from — that's a UX feature, not a
+> security decision."
+
+> "It's a router-link, Vue Router handles the URL, so it must be safe."
+
+> "It's just the search query showing what the user typed — of course it should render as-is."
+
+All three treat *router-adjacent* data (a `redirect` query param, a `:to` binding, a
+`route.params`/`route.query` value) as inherently trusted because it arrived through routing
+machinery rather than a form POST. Vue Router's own docs confirm the opposite: dynamic segments
+are "exposed... as `route.params`" with no escaping step described anywhere in the dynamic-
+matching guide (`repo evidence`, `/vuejs/router`) — they are raw strings lifted from the URL,
+exactly as attacker-controllable as any query-string or form value.
+
+## Officially grounded facts
+
+- **Redirect functions receive the live route object and can echo it verbatim.** Vue Router's
+  documented redirect patterns include function-based redirects that read `to.params`/`to.query`
+  directly: `redirect: to => ({ path: '/search', query: { q: to.params.searchText } })` and
+  `redirect: to => \`/redirected-path/${to.params.id}\`` (`repo evidence`, `/vuejs/router`,
+  redirect-and-alias / extending-routes guides). The mechanism for building a redirect target
+  from live route data is a first-class, documented feature — which is exactly why an
+  *unvalidated* version of the same mechanism (echoing a full attacker-supplied URL instead of a
+  path segment) is dangerous: the framework will not stop you.
+- **`router.push` accepts a bare string path with no origin/scheme validation of its own** —
+  `router.push('/users/eduardo')`, `router.push(\`/user/${username}\`)` (`repo evidence`,
+  `/vuejs/router`, navigation guide). If `username` (or any interpolated value) is instead a
+  full external URL or a `javascript:` string, `router.push` does not reject it — it is the
+  calling code's responsibility to validate before calling.
+- **`RouterLink`'s `:to` prop is commonly extended to bind directly to `:href` for external
+  links, gated only by an `isExternalLink` string check** — Vue Router's own
+  extending-router-link guide shows `:href="to"` used directly for values where
+  `typeof props.to === 'string' && props.to.startsWith('http')` (`repo evidence`,
+  `/vuejs/router`, extending-router-link guide). This is the documented pattern for handling
+  external links alongside internal ones — but note precisely what it does *not* include: any
+  scheme allowlist beyond the `http` prefix check. A value like `javascript:...` or
+  `httpjavascript:` crafted to defeat a naive `startsWith('http')` check is not excluded by this
+  documented example alone; production code needs an explicit protocol allowlist (see pattern
+  below), not just an `http`-prefix string check.
+- **`route.params`/`route.query` carry no built-in HTML-escaping** — confirmed by the dynamic-
+  matching guide's description of params as directly exposed URL segments (`repo evidence`,
+  `/vuejs/router`). Vue's *template* interpolation (`{{ }}`) auto-escapes when you render these
+  values normally; the risk is exclusively when a `route.params`/`route.query` value reaches a
+  `v-html` binding or a manual `.innerHTML` assignment, which bypass that auto-escaping by
+  design (`documentation-based`, Vue security guide — this specific `v-html`-is-unescaped claim
+  is general Vue template-compiler behavior, not a Vue-Router API, so it is grounded in the
+  `official_docs` Vue security guide rather than the `/vuejs/router` library).
+
+## Non-negotiable design rules
+
+### 1. Open redirect: validate against a same-origin/relative-path allowlist, not a blocklist
+
+The only acceptable fix for a `redirect`/`returnUrl` query value used in a post-auth redirect is
+allowlisting: confirm the value is a relative path starting with a single `/` (reject
+protocol-relative `//` and any value containing `://`), or resolve it with
+`new URL(value, window.location.origin)` and compare the resolved `origin` to the app's own
+origin. A denylist of "known bad" values (blocking `http://`/`https://` substrings, for example)
+is not sufficient — treat a blocklist-only approach as still a finding, since it is trivially
+bypassed by encoding or alternate schemes.
+
+### 2. Scheme injection: allowlist protocols explicitly, don't rely on prefix checks alone
+
+For any dynamic `:to`/`:href` fed by user-reachable input, require a visible allowlist check
+(e.g., `['http:', 'https:', 'mailto:'].includes(new URL(value, base).protocol)`) on the exact
+data-flow path. A `startsWith('http')` check (as shown in Vue Router's own external-link
+extension example) is a routing-decision heuristic (is this internal or external), not a
+security control — do not accept it as clearing a scheme-injection finding.
+
+### 3. Trace `v-html`/`innerHTML` sinks fed by route data back to the URL, not just to a variable name
+
+If a component does `<div v-html="route.query.bio">` or
+`el.innerHTML = route.params.description`, the origin is the URL itself — the most directly
+user-controlled input there is, requiring no stored/second-order step. Do not treat this as
+lower-severity than a stored-XSS path; a reflected payload via a shared link is exploitable
+immediately.
+
+### 4. Text interpolation and non-rendering uses of route data are not the defect
+
+`{{ route.query.q }}`, `:aria-label="route.params.id"`, passing `route.params.id` into an API
+call, or using it as a `v-if` condition are all safe — Vue's default interpolation escapes, and
+non-DOM-rendering uses have no injection sink at all. Only flag the specific `v-html`/`innerHTML`
+sink, not every place a component touches `route.params`/`route.query`.
+
+## Minimal safe implementation patterns
+
+Open redirect, validated:
+
+```js
+const SAFE_REDIRECT = /^\/(?!\/)/ // single leading slash, not protocol-relative
+
+function safeRedirectTarget(raw) {
+  return typeof raw === 'string' && SAFE_REDIRECT.test(raw) ? raw : '/'
+}
+
+router.push(safeRedirectTarget(route.query.redirect))
+```
+
+Scheme-validated dynamic link:
+
+```vue
+<script setup>
+const ALLOWED_SCHEMES = ['http:', 'https:', 'mailto:']
+
+function safeHref(url) {
+  try {
+    const parsed = new URL(url, window.location.origin)
+    return ALLOWED_SCHEMES.includes(parsed.protocol) ? parsed.href : '#'
+  } catch {
+    return '#'
+  }
+}
+</script>
+
+<template>
+  <a :href="safeHref(profile.websiteUrl)">Website</a>
+</template>
+```
+
+Route data into `v-html`, sanitized:
+
+```vue
+<script setup>
+import DOMPurify from 'dompurify'
+import { computed } from 'vue'
+import { useRoute } from 'vue-router'
+
+const route = useRoute()
+const safeQueryPreview = computed(() => DOMPurify.sanitize(String(route.query.q ?? '')))
+</script>
+
+<template>
+  <div v-html="safeQueryPreview"></div>
+</template>
+```
+
+Anti-patterns (do not approve):
+
+```js
+// Open redirect: unvalidated query value passed straight to router/window.
+router.push(route.query.redirect) // or: window.location.href = route.query.returnUrl
+```
+
+```vue
+<!-- Scheme injection: no protocol allowlist. -->
+<router-link :to="userProvidedProfileLink">Visit</router-link>
+```
+
+```vue
+<!-- Reflected XSS: route.query rendered via v-html with no sanitizer on the path. -->
+<div v-html="route.query.q"></div>
+```
+
+## Adversarial checklist
+
+- Does any code read `route.query.redirect`/`returnUrl` (or similarly named params) and pass it
+  to `router.push`, `router.replace`, or `window.location` without an allowlist check?
+- Is the allowlist check a same-origin/relative-path confirmation, or only a substring blocklist
+  (which does not count as a fix)?
+- Does any `:to`/`:href` binding's traced source include user-reachable input with no protocol
+  allowlist visible on that exact path?
+- Would `javascript:`, `data:`, or `vbscript:` reach any such binding unmodified?
+- Does any `v-html` or manual `.innerHTML` assignment's traced source include
+  `route.params`/`route.query` with no named sanitizer call on that exact path?
+- Is a redirect-loop or bypass reachable by feeding a guard's own redirect target from
+  unvalidated `to.query`/`to.params` (cross-reference `client-guards-and-control-flow.md`)?
+
+## Verification targets
+
+- Grep for `route.query.redirect`, `route.query.returnUrl`, `to.query.redirect`, and similar
+  names; trace each into `router.push(`, `router.replace(`, or `window.location`.
+- Grep for `:to="` and `:href="` bound to a non-literal expression; trace each backward through
+  props/computed/store to its origin.
+- Grep for `v-html` and `.innerHTML =` and trace each backward for any `route.params`/
+  `route.query` origin.
+- Grep for a scheme/protocol allowlist (`ALLOWED_SCHEMES`, `new URL(`, `.protocol ===`) near
+  each dynamic link binding found above, and confirm it sits on the traced path rather than
+  merely existing elsewhere in the file.
+- Grep for a sanitizer import (`dompurify` or an equivalent project utility) and confirm its
+  call site is on the traced `v-html`/`innerHTML` path.

package/skills/frontend/vue-router-navigation-security-review/references/workflow-and-output.md

@@ -0,0 +1,134 @@
+# Review Workflow and Findings Contract
+
+Use this reference for the step-by-step review procedure and the required output shape. Load
+the two domain references only for the specific defect class the routing code under review
+actually raises.
+
+## Prerequisites
+
+- Confirm Vue Router is actually in use (`package.json` — `vue-router`) and identify the major
+  version. Guard signatures (`next` third argument vs. return-value guards), redirect object
+  shape, and catch-all syntax (`/:pathMatch(.*)*` vs. legacy `*`) differ across Vue Router 3 vs.
+  4 — do not apply v4 syntax expectations to a v3 codebase or vice versa.
+- Identify whether the app runs in `history` mode (`createWebHistory`) or hash mode
+  (`createWebHistory` vs. `createWebHashHistory`) — the server-fallback concern
+  (`client-guards-and-control-flow.md`, rule 6) only applies to `history` mode.
+- Identify whether this is a meta-framework (Nuxt) rather than raw Vue Router — Nuxt's
+  `definePageMeta`/route middleware wraps the same underlying guard concepts but with different
+  file-based conventions; note this explicitly rather than assuming `router.beforeEach` exists
+  verbatim in a Nuxt app.
+
+## Workflow
+
+1. **Locate every navigation guard.** Grep for `router.beforeEach(`, `beforeEnter:` on route
+   definitions, and (for Nuxt) `middleware/` files or `definePageMeta({ middleware: ... })`.
+   Read each guard's full body.
+2. **For each guard that gates a protected route, look for the server-side counterpart.**
+   Identify what API/data endpoint the protected route depends on and search for evidence
+   (tests, comments, a BFF layer, an API contract doc) that the endpoint independently enforces
+   authorization server-side. Absence of such evidence is the finding — see
+   `client-guards-and-control-flow.md`.
+3. **Trace every redirect.** For guard-returned redirects, `next(...)` calls, and any
+   post-login redirect flow, determine: is the target hardcoded/same-origin, or built from
+   `to.query`/`to.params`/`route.query`? If the latter, trace whether it is validated against a
+   same-origin/relative-path allowlist before use. See `open-redirect-and-injection.md`.
+4. **Enumerate every dynamic `:to`/`:href` binding in scope.** Trace each backward through
+   props, computed values, and store state to its origin. Check for a visible protocol
+   allowlist on the exact traced path when the origin includes user-reachable input.
+5. **Enumerate every `v-html`/`innerHTML` sink in scope that touches `route.params`/
+   `route.query`.** Trace backward the same way; check for a named sanitizer call on the exact
+   path.
+6. **Check guard self-exclusion and route-table ordering.** For every unconditional
+   redirect-on-guard, confirm a self-exclusion check exists for the guard's own redirect target.
+   Read the full `routes` array in declaration order and check whether a catch-all or broad
+   pattern could shadow a route that should require authentication.
+7. **Check `history`-mode server configuration when in scope.** If `createWebHistory()` is used,
+   look for a server/proxy config file with an SPA-fallback rule; note explicitly if that file
+   is outside the review's scope rather than assuming correctness.
+8. **Produce ranked findings** using the output contract below.
+
+## Decision tree
+
+- A guard redirects unauthenticated users away from a protected route, and no evidence exists
+  that the route's underlying API/data endpoint independently enforces authorization
+  server-side → **HIGH** finding, `client-guard-as-sole-authz`. Cite Vue Router's own framing of
+  guards as client-side navigation control flow (`repo evidence`) plus general server-side-
+  enforcement practice (`inference`/`documentation-based`).
+- A guard redirects unauthenticated users away from a protected route, **and** the route's
+  server endpoint is confirmed to independently reject unauthorized requests → not a finding;
+  state explicitly that the guard is correctly UX-only.
+- A post-auth redirect flow passes `route.query.redirect`/`returnUrl` (or equivalent) into
+  `router.push`/`window.location` with no same-origin/relative-path validation → **HIGH**
+  finding, `open-redirect`.
+- The same flow validates the value against a same-origin/relative-path allowlist before use →
+  not a finding.
+- A dynamic `:to`/`:href` binding's traced source includes user-reachable input with no
+  protocol allowlist on the exact path → **HIGH** finding, `scheme-injection` (reachable via a
+  crafted profile/link field triggering `javascript:`/`data:` execution on click).
+- The same binding's source is a literal, a named-route object, or already passes a protocol
+  allowlist on the traced path → not a finding.
+- `route.params`/`route.query` reaches a `v-html` binding or manual `.innerHTML` assignment
+  with no named sanitizer call on the exact traced path → **HIGH** finding, `reflected-xss`.
+- `route.params`/`route.query` is used only via text interpolation, non-rendering logic, or
+  passes through a sanitizer call on the traced path → not a finding.
+- An unconditional redirect-on-guard has no self-exclusion check for its own redirect target →
+  **HIGH** finding, `redirect-loop` (Vue Router's own docs prescribe the `to.name !== 'Login'`
+  self-exclusion pattern as required, not optional).
+- The guard already includes a self-exclusion check → not a finding.
+- A guard's redirect target (or a `next(...)` argument) is itself built from unvalidated
+  `to.query`/`to.params` → **HIGH** finding, `open-redirect` (the guard reintroduces the same
+  defect class it exists to prevent) — cross-reference the open-redirect rule above.
+- A catch-all route (`/:pathMatch(.*)*`) renders `route.params.pathMatch` through an
+  unsanitized sink, or route-table ordering lets it shadow a route that should require auth →
+  **MEDIUM-to-HIGH** finding, `catch-all-misconfig`, depending on what is actually exposed.
+- A catch-all route renders only a static not-found component with no broader-than-intended
+  matching (confirmed via route-table order) → not a finding.
+- `createWebHistory()` is used with no evidence of a corresponding server-side SPA-fallback
+  rule in scope → note as an **open question**, not a confirmed finding, unless the server
+  config is actually in the reviewed diff/repo and shown to be missing or overly broad, in
+  which case it is a **MEDIUM** finding, `history-mode-server-misconfig`.
+- `createWebHistory()` is paired with a reviewed, correctly scoped server-fallback rule → not a
+  finding; state it as reviewed-and-safe.
+
+## Output contract
+
+Every response from this skill must return:
+
+1. **Scope** — the guard(s), redirect flow(s), dynamic link binding(s), route table, and/or
+   `v-html`/`innerHTML` sink(s) reviewed.
+2. **Ranked findings** — each with file:line, defect category (`client-guard-as-sole-authz` /
+   `open-redirect` / `scheme-injection` / `reflected-xss` / `redirect-loop` /
+   `catch-all-misconfig` / `history-mode-server-misconfig`), the concrete data-flow trace (every
+   hop from origin to sink, or the guard-to-endpoint gap for the authz-boundary category), and
+   a fix sketch matching Vue Router's documented pattern.
+3. **Server-side enforcement status for every guard finding** — an explicit statement of
+   whether evidence of independent server-side authorization was found, and where; never infer
+   server enforcement exists without evidence on the traced path.
+4. **Evidence level per finding** — `repo evidence`, `documentation-based`, or `inference`.
+   Label structural-risk findings (e.g., "no evidence of server enforcement") as structural
+   risk, not confirmed exploitation — proving actual bypass requires a live request against the
+   real API, which this skill does not perform.
+5. **Verdict** — approve / approve-with-notes / block.
+6. **Open questions or out-of-scope items** — e.g., "confirming the API layer actually rejects
+   unauthorized requests requires a live request or reading server-side code outside this
+   diff's scope," or "server SPA-fallback configuration is outside the reviewed files; flag for
+   a separate infra review."
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve a route as "protected" solely because a `beforeEach`/`beforeEnter` guard redirects
+  unauthenticated users, with no evidence the underlying API/data endpoint independently
+  enforces authorization — a client-side redirect is not access control,
+- treat a redirect-target validation as done because "we checked it's a string" or "we blocked
+  `http://`" — a type check or substring blocklist is not an allowlist and does not clear an
+  open-redirect finding,
+- approve a dynamic link binding because "Vue Router handles URLs safely" — Vue Router does not
+  validate URL schemes; that is application-code responsibility,
+- skip tracing a `route.params`/`route.query` value into `v-html` because "it's just the search
+  box echoing what the user typed" — a reflected payload via a shared URL is exploitable
+  immediately, with no stored/second-order step required,
+- downgrade a missing self-exclusion check in a redirect guard to informational because "it
+  hasn't looped in testing" — Vue Router's own docs treat this check as required, not optional,
+  and the loop condition depends on navigation order that testing may not have exercised.

package/skills/frontend/vue-ssr-security-review/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: vue-ssr-security-review
+description: Statically review Vue 3 SSR entry points and templates for cross-request state pollution (module-scope reactive state, non-per-request app/store creation) and injection via unsanitized v-html or unvalidated dynamic href/src bindings, grounded in Vue's own SSR and security-best-practices guidance.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: security
+---
+
+# Vue SSR Security Review
+
+## Purpose
+
+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."
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review an SSR entry point (`entry-server.js`/`.ts`, or equivalent request-handling code that creates the Vue app for rendering),
+- assess whether a `v-html` usage is safe,
+- investigate a report of users seeing another user's data on first load or on a subsequent request — the classic cross-request state pollution symptom,
+- perform a pre-launch security review of an SSR Vue application.
+
+Do not use this skill for:
+
+- a purely client-rendered (non-SSR) Vue app with no server-rendering entry point — cross-request state pollution does not apply, because each browser tab has its own isolated JS realm and there is no shared server process handling concurrent requests,
+- Options API/Composition API architecture review with no security angle (composable extraction quality, reactivity-boundary correctness) — use `vue-composition-api-architecture-review` instead,
+- a bug that requires live traffic reproduction (concurrent-request load testing, session-replay capture) to confirm exploitation — static analysis proves the structural risk, not that it has already been exploited in production.
+
+## Context7 Documentation Protocol
+
+- Resolve the Vue library ID with `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`.
+- Before flagging a specific pattern as cross-request state pollution, confirm the app is actually SSR (a request-handling entry point exists that renders on the server) — the pollution risk is specific to SSR's single, long-lived Node.js process handling many requests; it does not apply to a client-only SPA.
+- Read `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.
+- If Context7 is unavailable, fall back to the `official_docs` URLs in this skill's `metadata.json` and label the claim `documentation-based, unverified against current release`.
+
+## Lean operating rules
+
+- Cross-request state pollution and injection findings default to HIGH severity. This is a security-scoped skill: do not downgrade a structural cross-request-pollution risk or an untraced `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.
+- Trace every finding to a concrete file:line and a concrete data-flow path. A finding that says "this might leak state" or "this v-html might be unsafe" without showing the specific module-scope declaration, the specific reachability path, or the specific unsanitized data-flow trace is not a valid finding — it is a guess.
+- Do not treat every module-scope declaration as a pollution risk. An immutable, non-reactive constant (a route table, a static config object, a compiled template) declared at module scope is safe. Only *mutable or reactive* state reachable from an SSR-rendered component's render path is the risk — check both properties (mutability/reactivity, and reachability) before flagging.
+- Do not approve a `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.
+- Check dynamic `: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.
+- Watch for per-request factory functions that appear correct (a fresh `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.
+- Never execute, build, or run application code, and never send live requests, as part of this review; this is a static-review skill (Read/Grep/Glob only).
+- Load only the reference needed for the concern in scope.
+
+## References
+
+Load these only when needed:
+
+- [Review workflow and findings contract](references/workflow-and-output.md) — use for the step-by-step review procedure, the state-pollution/injection decision tree, and the required output shape.
+- [Cross-request state pollution](references/cross-request-state-pollution.md) — load only when reviewing an SSR entry point, tracing app/store/router creation, or investigating a suspected cross-request data-leak symptom.
+- [Injection: v-html and dynamic URL bindings](references/injection-and-dynamic-urls.md) — load only when the review scope includes a `v-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.
+
+## Response minimum
+
+Return, at minimum:
+
+- the SSR entry point(s), module-scope declarations, and/or template bindings in scope,
+- ranked findings with file:line evidence, defect category (`state-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,
+- for every `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,
+- evidence level per finding (`repo evidence`, `documentation-based`, or `inference`), with structural risk findings explicitly labeled as structural risk, not as confirmed-exploited,
+- verdict (approve / approve-with-notes / block),
+- open questions or scope the review could not cover (e.g., "confirming actual cross-request leakage requires concurrent-request load testing, not static review").

package/skills/frontend/vue-ssr-security-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "vue-ssr-security-review",
+  "name": "Vue SSR Security Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews Vue 3 SSR entry points and templates for cross-request state pollution (module-scope reactive state, non-per-request app/store/router creation) and injection via unsanitized v-html or unvalidated dynamic href/src bindings, grounding claims via Context7 and Vue's own SSR and security best-practices documentation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://vuejs.org/guide/scaling-up/ssr.html",
+    "https://vuejs.org/guide/best-practices/security.html",
+    "https://owasp.org/www-project-top-ten/",
+    "https://owasp.org/www-community/attacks/xss/"
+  ],
+  "security_notes": "This skill's entire scope is security-critical: cross-request state pollution is a data-exposure defect (potential cross-tenant/cross-user leakage) and unsanitized v-html is a stored/reflected XSS vector. Every finding in this skill defaults to HIGH severity unless proven otherwise with concrete sanitizer evidence. Static-review-only skill: it reads and greps SSR entry points and template source but never executes, builds, or runs application code, and never sends live requests.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/vue-ssr-security-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}