@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.0

package/skills/frontend/nuxt-fullstack-security-review/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "nuxt-fullstack-security-review",
+  "name": "Nuxt Fullstack Security Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews Nuxt 3/4 full-stack code for private secrets exposed via runtimeConfig.public/NUXT_PUBLIC_* env vars, useState/module-scope cross-request state pollution in Nitro, server-route SSRF via $fetch/ofetch with blind useRequestHeaders/credential forwarding, NuxtPayload/useState serialization reaching an XSS sink, and missing security response headers (routeRules headers, the nuxt-security module), grounding claims via Context7 and Nuxt's own documentation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://nuxt.com/docs/guide/going-further/runtime-config",
+    "https://nuxt.com/docs/getting-started/state-management",
+    "https://nuxt.com/docs/guide/directory-structure/server",
+    "https://nuxt.com/docs/getting-started/data-fetching",
+    "https://nuxt.com/docs/api/composables/use-request-headers",
+    "https://nuxt.com/docs/api/composables/use-response-header",
+    "https://nuxt.com/docs/guide/concepts/rendering",
+    "https://owasp.org/www-community/attacks/Server_Side_Request_Forgery",
+    "https://owasp.org/www-community/attacks/xss/"
+  ],
+  "security_notes": "This skill's entire scope is security-critical: a runtimeConfig.public/NUXT_PUBLIC_* secret is a client-bundle credential leak, useState/module-scope pollution in Nitro is a cross-tenant/cross-user data-exposure defect, server-route SSRF and blind header forwarding can leak credentials or reach internal network targets, payload/useState reaching an unsanitized sink is XSS, and missing security response headers weakens the app's baseline browser-side defenses. Every finding in this skill defaults to HIGH severity unless proven otherwise with concrete evidence (a private key correctly scoped, an allowlisted outbound host, a sanitizer visibly on the traced path, or documented header coverage of the routes in scope). Static-review-only skill: it reads and greps nuxt.config.ts, composables/plugins/server code, and templates but never executes, builds, or runs application code, and never sends live requests.",
+  "last_verified": "2026-07-03",
+  "path": "skills/frontend/nuxt-fullstack-security-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/nuxt-fullstack-security-review/references/acceptance-rubric.md

@@ -0,0 +1,96 @@
+# Acceptance Rubric (write this first — it is the failing test)
+
+This rubric is the spec for `nuxt-fullstack-security-review`. Every item below must be
+covered by an explicit operating rule, decision-tree branch, or reference section before
+this skill ships. `SKILL.md` and the other `references/*.md` files are written to satisfy
+this list, not the other way around.
+
+## MUST catch (true positives)
+
+1. **Private secret placed under `runtimeConfig.public.*`.** A key holding a secret
+   (API key, DB credential, signing secret, third-party token) declared inside the
+   `public` block of `runtimeConfig` in `nuxt.config.ts` — or a `NUXT_PUBLIC_*`
+   environment variable feeding one — ships to the client JS bundle. HIGH. Evidence:
+   Context7 `/websites/nuxt_4_x` confirms only `runtimeConfig.public.*` (and
+   `runtimeConfig.app.*`) are exposed to the client; every other key is server-only,
+   and only an uppercase `NUXT_`-prefixed env var overrides a *matching* runtimeConfig
+   key at runtime.
+2. **Private secret with a name/shape suggesting sensitivity kept at top-level
+   `runtimeConfig` but actually read from a public-scoped variable, or accidentally
+   duplicated into `public` "for convenience" (e.g., a client composable needs the same
+   value).** Still HIGH — the fix is a server-only proxy endpoint, not exporting the
+   secret to `public`.
+3. **`useState` or module-scope `ref()`/`reactive()`/mutable object declared outside any
+   composable/component function body**, used to hold per-user or per-request data
+   (session, cart, auth token, request-specific query results) in server-rendered Nitro
+   code. Because Nitro is a single long-lived process serving concurrent requests, this
+   is cross-request state pollution — HIGH, structural, regardless of whether it has
+   been observed leaking.
+4. **A composable that *looks* per-request (invoked inside `setup()`/an event handler)
+   but closes over a shared module-level cache/singleton/mutable default parameter**,
+   defeating the apparent isolation. HIGH.
+5. **`server/api/*` route (`defineEventHandler`) calling `$fetch`/`ofetch` with a
+   URL built from user-controlled input (route param, query string, request body)
+   with no host allowlist** — classic SSRF: an attacker can redirect the server's
+   outbound request to an internal address or arbitrary host. HIGH.
+6. **A server route reading `useRequestHeaders()` (or forwarding `event.node.req.headers`
+   directly) and blindly forwarding all headers — or specifically `authorization`/
+   `cookie` — to a third-party/user-controlled outbound `$fetch` call** without an
+   allowlist of headers and without restricting the destination host. HIGH — this
+   leaks the current user's credentials to whatever host the URL resolves to.
+7. **`useState`/payload data containing user-controlled/echoed content (a query param,
+   a comment body, a profile field) serialized into the SSR payload and then rendered
+   unescaped** (e.g., interpolated with `v-html`, or written into an inline
+   `<script>`/`<style>` block by custom server middleware bypassing Nuxt's own
+   `devalue`-based payload serialization) → XSS. HIGH. (Nuxt's own payload
+   serialization via `devalue` is not itself an XSS sink; the finding is about
+   *what renders that payload data unescaped afterward* or about a hand-rolled
+   payload/script-injection path that bypasses `devalue`.)
+8. **No security response headers configured anywhere** (no `routeRules` `headers`
+   entries, no `nuxt-security` module, no middleware calling `useResponseHeader`) for
+   an app that serves authenticated pages, handles forms, or embeds third-party
+   content — missing CSP/X-Frame-Options/X-Content-Type-Options is a MEDIUM-to-HIGH
+   finding depending on what the app does (a public informational-only site with no
+   auth and no user input is lower severity than a logged-in dashboard).
+
+## MUST NOT flag (false positives to actively avoid)
+
+9. A value correctly declared as a **private** `runtimeConfig` key (outside `public`),
+   even if consumed only server-side in `server/api/*` — this is the *correct* pattern
+   and must not be flagged just because "secrets in config feel risky."
+10. `runtimeConfig.public.*` holding genuinely non-secret data (a base API URL, a
+    feature flag, a public analytics ID) — public-by-design values are not findings.
+11. `useState`/`ref`/`reactive` declared **inside** a composable function, component
+    `setup()`, or plugin factory that runs per-request/per-component-instance — this is
+    the documented, safe pattern; do not flag every `useState` call site.
+12. A module-scope `const` holding an **immutable** value (a frozen route table, a
+    static config object, a compiled regex, a constant lookup map) with no runtime
+    mutation path — immutable module-scope constants are safe to share across
+    requests.
+13. A `server/api/*` route whose `$fetch`/`ofetch` target is a **hardcoded or
+    allowlisted** host (e.g., validated against a fixed list of trusted upstream
+    domains, or the URL is entirely server-config-derived with no user input in the
+    host/path) — do not flag SSRF when the destination is not attacker-influenceable.
+14. `event.$fetch(...)` used deliberately to forward request context to another
+    **internal** Nitro route for legitimate context propagation, with no external host
+    involved — not an SSRF/credential-leak finding by itself; only flag when the
+    *destination* is external/user-controlled or when *sensitive* headers are
+    forwarded to it without justification.
+15. An app that already sets a documented security header mechanism (an explicit
+    `routeRules` `headers` block with CSP/HSTS/etc., or the `nuxt-security` module
+    configured) — do not flag "missing headers" when a header-setting mechanism is
+    present and covers the routes in scope; only flag genuine gaps (e.g., headers set
+    for `/` but not for `/admin/**`).
+
+## Evidence discipline
+
+- Every finding must cite file:line and a concrete data-flow trace (declaration →
+  reachability, or origin → sink).
+- Every framework-behavior claim in the finding write-up must be labeled
+  `documentation-based` (Context7-confirmed against `/websites/nuxt_4_x` or
+  `/websites/nuxt_3_x`), `repo evidence` (observed directly in the file under review),
+  or `inference` (reasonable extrapolation not directly stated in either source —
+  e.g., community conventions like the third-party `nuxt-security` module's exact
+  default header set, which Context7's Nuxt-core docs do not themselves enumerate).
+- Do not invent API names. If Context7 does not confirm an API or default, say so and
+  label the claim `inference`.

package/skills/frontend/nuxt-fullstack-security-review/references/runtime-config-and-cross-request-state.md

@@ -0,0 +1,193 @@
+# runtimeConfig Exposure and Cross-Request State Pollution
+
+Use this reference when the review scope includes `nuxt.config.ts`'s `runtimeConfig`
+block, any `.env`/`NUXT_*` variable naming, or `useState`/module-scope reactive
+declarations reachable from server-rendered code.
+
+## Part 1 — runtimeConfig: private vs public split
+
+### What people get wrong
+
+The naive assumption is:
+
+> "I put it in `runtimeConfig`, so it's server-only."
+
+Wrong — only *part* of `runtimeConfig` is server-only. Nuxt's own config API
+distinguishes two zones inside the same object:
+
+```ts
+export default defineNuxtConfig({
+  runtimeConfig: {
+    // Private keys are only available on the server
+    apiSecret: '123',
+
+    // Public keys that are exposed to the client
+    public: {
+      apiBase: process.env.NUXT_PUBLIC_API_BASE || '/api',
+    },
+  },
+})
+```
+
+(`documentation-based`, Context7 `/websites/nuxt_4_x`, `useRuntimeConfig`/
+`nuxt.config` API reference and the runtime-config guide.) Everything nested under
+the `public` key (and, per the same source, the `app` key) is serialized into the
+client bundle and readable by anyone who opens dev tools. Everything else in
+`runtimeConfig` stays server-only.
+
+### The environment-variable trap
+
+Context7 confirms two hard rules for env-var overrides (`documentation-based`,
+`/websites/nuxt_4_x`, "Runtime Config > Exposing > Environment Variables" and the
+migration guide):
+
+1. Only variables **already declared** in `nuxt.config`'s `runtimeConfig` can be
+   overridden at runtime — arbitrary env vars are never auto-exposed.
+2. Only an **uppercase environment variable prefixed `NUXT_`**, using `_` to
+   separate nested keys, overrides the matching config path. A `NUXT_PUBLIC_*`
+   variable maps to a key under `public`; a `NUXT_*` variable without `PUBLIC`
+   maps to a private top-level key.
+
+The security-relevant consequence: a developer who names an env var
+`NUXT_PUBLIC_API_SECRET` — intending it to *feel* private because of the word
+"SECRET" — has just told Nuxt to expose it to the client, because the naming
+convention that controls exposure is structural (`public.*` nesting / the
+`PUBLIC` segment), not the variable's English-language name.
+
+### Verification targets
+
+- Grep `nuxt.config.*` for `runtimeConfig:` and read the full block, including the
+  nested `public: { ... }` object.
+- For every key under `public`, ask: does its name or the value it defaults to
+  (`process.env.*`) suggest a secret, credential, signing key, or internal
+  hostname? If yes → HIGH finding, move it out of `public` (or behind a
+  server-only proxy endpoint that reads the private key and returns only what the
+  client needs).
+- For every key **outside** `public` (private), confirm it is never re-exported
+  into a public-scoped value elsewhere (e.g., a plugin or composable doing
+  `useRuntimeConfig().public.foo = useRuntimeConfig().apiSecret` — an anti-pattern
+  that defeats the private/public split at runtime).
+- Grep `.env`, `.env.*`, and deployment/CI config for `NUXT_PUBLIC_*` variable
+  names; confirm each maps to a genuinely public value in `nuxt.config`.
+- Do not flag a private key merely for existing — that is the correct, safe
+  pattern (rubric item 9). Only flag actual public-zone exposure or private→public
+  leakage.
+
+### Fix sketch
+
+```ts
+// nuxt.config.ts — correct
+export default defineNuxtConfig({
+  runtimeConfig: {
+    apiSecret: '', // NUXT_API_SECRET — server-only, never reaches the client
+    public: {
+      apiBase: '', // NUXT_PUBLIC_API_BASE — fine to expose
+    },
+  },
+})
+```
+
+```ts
+// server/api/proxy.ts — client needs data derived from the secret,
+// so it calls a server route, never the secret itself
+export default defineEventHandler(async (event) => {
+  const config = useRuntimeConfig(event)
+  const result = await $fetch('https://upstream.example.com/data', {
+    headers: { Authorization: `Bearer ${config.apiSecret}` },
+  })
+  return result // only the derived, non-secret payload leaves the server
+})
+```
+
+## Part 2 — useState / module-scope cross-request state pollution
+
+### What people get wrong
+
+The naive assumption is:
+
+> "Nuxt handles SSR for me, so any state I declare is automatically per-request."
+
+Wrong. Nitro (Nuxt's server engine) is a single long-lived Node.js process handling
+many concurrent requests. Context7 confirms the exact failure mode directly
+(`documentation-based`, `/websites/nuxt_4_x`, "Auto-imports > Built-in Auto-imports"):
+Vue/Nuxt tracks the current component instance (and Nuxt's own `nuxtApp`) via a
+transient global reference specifically to avoid "cross-request state pollution
+(leaking a shared reference between two users)." That same guide's State
+Management page states the rule as a best practice directly: never define
+`const state = ref()` outside of `<script setup>` or a `setup()` function — doing
+`export myState = ref({})` "would result in state shared across requests on the
+server and can lead to memory leaks." (`documentation-based`,
+`/websites/nuxt_4_x`, "State Management > Best Practices.")
+
+`useState` itself is the documented safe replacement: an "SSR-friendly `ref`
+replacement" whose "value will be preserved after server-side rendering (during
+client-side hydration) and shared across all components using a unique key"
+(`documentation-based`, same source) — but `useState` is only safe when invoked
+inside a component/composable/plugin function body, where Nuxt's per-request
+context tracking scopes it correctly. Calling `useState` (or any `ref`/`reactive`)
+at true module scope defeats that scoping.
+
+### Non-negotiable design rules
+
+1. **Classify every module-scope declaration by mutability/reactivity, then by
+   reachability** — same two-axis test as any SSR framework: is it
+   `ref()`/`reactive()`/`useState()`/a mutable object or array literal (risk), or an
+   immutable constant (safe)? Is it imported/read/written by any
+   server-rendered composable, plugin, or `server/api` handler (reachable), or
+   truly dead/unused (not a finding in this scope)?
+2. **A composable wrapper does not automatically fix it.** `const useX = () =>
+   useState('x')` is the documented safe pattern *only* because `useState`'s
+   internal key-based lookup is itself scoped per Nuxt-app-instance/per-request.
+   A hand-rolled module-scope cache object that a composable merely *reads* from
+   (rather than routing through `useState`/a genuinely per-request store) is not
+   fixed by wrapping the read in a function — trace what the function actually
+   touches, not just its outer shape.
+3. **Server-side (`server/api`, `server/middleware`) module-scope mutable state is
+   just as much at risk as client/universal composable state** — Nitro's event
+   handlers run in the same long-lived process. A module-level `let cache = {}`
+   written to inside a `defineEventHandler` and read by a later request from a
+   different user is a textbook cross-request leak, independent of Vue/useState
+   entirely.
+4. **Closures over shared mutable state defeat an otherwise-correct factory** — a
+   `defineEventHandler` that looks correct because it doesn't declare state at
+   module scope can still close over a module-level mutable variable from its
+   enclosing file.
+
+### Verification targets
+
+- Grep for `useState(` calls and confirm each is inside a `<script setup>` block,
+  `setup()` function, composable function body, or Nuxt plugin factory — not at
+  a file's top level.
+- Grep for `ref(`/`reactive(` outside any function body across `composables/`,
+  `plugins/`, `server/api/`, `server/middleware/`, and any file imported by them.
+- Grep `server/` for `let `/mutable `const {}`/`const []` declarations at module
+  scope; check whether any `defineEventHandler` in the same file (or importing
+  the module) reads or writes them.
+- For each hit, trace reachability: is it imported by any server-rendered route,
+  composable, or middleware that runs per-request? If no server-rendered code
+  path reaches it, it is not a finding in this review's scope (rubric item 12 for
+  immutable data; otherwise flag as dead code, not a security finding).
+
+### Fix sketch
+
+```ts
+// BAD — server/api/session.ts: module-scope mutable object shared across all requests
+const lastUser: Record<string, unknown> = {}
+export default defineEventHandler((event) => {
+  lastUser.id = getQuery(event).userId // every concurrent request writes the SAME object
+  return lastUser
+})
+```
+
+```ts
+// GOOD — no shared mutable state; everything is derived fresh per request
+export default defineEventHandler((event) => {
+  const userId = getQuery(event).userId
+  return { id: userId }
+})
+```
+
+```ts
+// GOOD — universal/component state via useState, invoked inside a composable
+export const useCounter = () => useState('counter', () => 0)
+```

package/skills/frontend/nuxt-fullstack-security-review/references/ssrf-payload-and-response-headers.md

@@ -0,0 +1,264 @@
+# Server-Route SSRF, Header Forwarding, Payload XSS, and Missing Response Headers
+
+Use this reference when the review scope includes a `server/api/*` or
+`server/routes/*` event handler (`defineEventHandler`), any `$fetch`/`ofetch`/
+`event.$fetch`/`useRequestFetch` call inside server code, a `useState`/payload
+value that renders into a template, or `nuxt.config.ts`'s `routeRules`.
+
+## Part 1 — server route SSRF via $fetch/ofetch + header forwarding
+
+### What people get wrong
+
+The naive assumption is:
+
+> "It's just a server-side fetch, not user input rendered in the browser, so it
+> can't be a security issue."
+
+Wrong on two counts. First, if the **target URL** of a server-side `$fetch` call
+is built from user-controlled input (a route param, query string, or request
+body) with no allowlist, the server itself becomes an attacker-controlled
+HTTP client — a Server-Side Request Forgery (SSRF) primitive that can reach
+internal network addresses, cloud metadata endpoints, or arbitrary hosts the
+attacker chooses. Second, Nuxt's own docs draw a sharp, explicit line around
+**header forwarding** that is easy to miss:
+
+- Bare `$fetch(...)` inside a server route does **not** forward the incoming
+  request's headers or context by default (`documentation-based`,
+  `/websites/nuxt_4_x`, "Forwarding Context & Headers": "By default, neither the
+  headers from the incoming request nor the request context are forwarded when
+  making fetch requests in server routes.")
+- `event.$fetch(...)` is the documented way to forward the request context and
+  headers (`documentation-based`, same source): `export default
+  defineEventHandler((event) => { return event.$fetch('/api/forwarded') })`.
+- `useRequestFetch()` is the documented composable for explicitly forwarding the
+  current user's headers and cookies during SSR when plain `$fetch` would not
+  include them (`documentation-based`, `/websites/nuxt_4_x`,
+  `useRequestFetch` API reference).
+- Nuxt's data-fetching guide states the caution directly: "Exercise caution when
+  proxying headers to external APIs, only including those that are strictly
+  necessary. Headers like 'host', 'accept', 'content-length', 'content-type',
+  and various 'x-forwarded' or 'cf-' headers should generally not be proxied."
+  (`documentation-based`, `/websites/nuxt_4_x`, "$fetch > Pass Client Headers to
+  the API.")
+- `useRequestHeaders(['authorization'])` is documented specifically to proxy the
+  `authorization` header to an internal isomorphic `$fetch` call during SSR
+  (`documentation-based`, `/websites/nuxt_3_x`, `useRequestHeaders` API
+  reference, "Proxying Authorization Header in SSR").
+
+The security-relevant synthesis: **there is no built-in URL validation on
+`$fetch`/`ofetch`/`event.$fetch` targets**, and **there is no built-in header
+allowlist** on what `event.$fetch`/`useRequestFetch`/manually-forwarded headers
+send onward. Both are the calling code's responsibility. A route that (a) builds
+its outbound URL from user input and (b) forwards the current user's
+`authorization`/`cookie` header to that user-influenceable destination combines
+SSRF with credential exfiltration.
+
+### Non-negotiable design rules
+
+1. **Trace the outbound URL to its origin.** For every `$fetch`/`ofetch`/
+   `event.$fetch`/`useRequestFetch` call in a `server/api`/`server/routes`
+   handler, find where the URL string comes from. If any segment (host, path,
+   or query) is built from `getQuery(event)`, `getRouterParam(event, ...)`,
+   `readBody(event)`, or an equivalent user-reachable source, with no allowlist
+   check against a fixed set of trusted hosts before the call — HIGH SSRF
+   finding.
+2. **A hardcoded or allowlisted host is not a finding.** If the destination host
+   is a literal string, an env-config value with no user input in it, or the
+   user-supplied portion is validated against an explicit allowlist of trusted
+   hosts before the request fires, do not flag it (rubric item 13).
+3. **Trace what headers actually get forwarded, and to where.** `event.$fetch`
+   forwards request context/headers by default — check whether the destination
+   is internal (same-origin Nitro route) or external. Forwarding to an internal
+   route with no external network hop is not a credential-leak finding by
+   itself (rubric item 14). Forwarding `authorization`/`cookie` to an external
+   or user-influenceable host — with no allowlist limiting which headers cross
+   that boundary — is HIGH.
+2b. **Manual, unfiltered header spreading is worse than `event.$fetch`.** Code
+   that reads `event.node.req.headers` (or `getHeaders(event)`) and spreads the
+   entire object into an outbound `$fetch`'s `headers` option forwards
+   everything, including headers Nuxt's own docs say should generally not be
+   proxied (`host`, `accept`, `content-length`, `content-type`,
+   `x-forwarded-*`, `cf-*`) — flag this even before considering the destination,
+   since it also risks breaking the outbound request's own framing/routing
+   semantics, and flag it as HIGH if any sensitive header (`authorization`,
+   `cookie`) is in the spread and the destination is external or
+   user-influenceable.
+
+### Verification targets
+
+- Grep `server/api/` and `server/routes/` for `$fetch(`, `ofetch(`,
+  `event.$fetch(`, `useRequestFetch(`, `useRequestHeaders(`, `getHeaders(`.
+- For each `$fetch`-family call, read backward to the URL argument's full
+  construction; flag string concatenation/template literals combining a fixed
+  base with a user-reachable variable, or a bare user-supplied URL.
+- For each `useRequestHeaders(...)` or `getHeaders(...)` call, check what keys
+  are requested/forwarded and where the result is used downstream.
+
+### Fix sketch
+
+```ts
+// BAD — server/api/proxy.ts: user controls the entire outbound host
+export default defineEventHandler(async (event) => {
+  const { url } = getQuery(event)
+  return $fetch(url as string) // SSRF: attacker can point this at internal services
+})
+```
+
+```ts
+// GOOD — allowlisted upstream host, no user control over destination
+const ALLOWED_HOSTS = new Set(['api.trusted-partner.com'])
+
+export default defineEventHandler(async (event) => {
+  const { path } = getQuery(event)
+  const target = new URL(String(path), 'https://api.trusted-partner.com')
+  if (!ALLOWED_HOSTS.has(target.host)) {
+    throw createError({ statusCode: 400, statusMessage: 'Invalid target' })
+  }
+  return $fetch(target.toString())
+})
+```
+
+## Part 2 — NuxtPayload / useState serialization into rendered HTML
+
+### What people get wrong
+
+The naive assumption is:
+
+> "Nuxt serializes my state into the payload automatically, so whatever I put in
+> `useState` is handled safely by the framework."
+
+Partially wrong. Nuxt 3/4's payload mechanism (`nuxtApp.payload`, covering
+`data` from `useFetch`/`useAsyncData` and `state` from `useState`) is serialized
+for transfer from server to client using `devalue`, which supports "advanced
+data types beyond basic JSON, such as Dates, Maps, Sets, refs, reactives, and
+NuxtErrors" (`documentation-based`, `/websites/nuxt_3_x`, "Serializing Data From
+Server to Client" / `useNuxtApp` payload reference). `devalue`-based
+serialization itself is not an HTML-injection sink — it produces a JS
+expression, not raw HTML concatenation. The actual risk this skill flags is
+**what happens after** payload data is revived on the client:
+
+- If a `useState`/payload value holding user-controlled content (an echoed
+  query param, a comment body, a profile field from an API that itself echoes
+  other users' submissions) is later rendered with `v-html` anywhere in the app,
+  that is a standard unsanitized-`v-html` XSS finding — the payload is simply
+  the transport, not the sink. Trace the value from `useState`/payload through
+  to its eventual render, exactly as in an XSS review of any Vue app.
+- A custom payload plugin (`definePayloadReducer`/`definePayloadReviver`,
+  documented in `/websites/nuxt_3_x`'s `useNuxtApp` reference) that hand-builds
+  a serialized representation without going through `devalue` — or any custom
+  server middleware that writes directly into the rendered HTML's inline
+  `<script>` tag instead of relying on Nuxt's own payload injection — is a
+  distinct, higher-risk pattern: it bypasses the framework's serialization path
+  entirely and must be checked for proper escaping by hand (`inference`: Nuxt's
+  docs describe the reducer/reviver extension point but do not themselves
+  discuss its injection risk, so grade this claim as inference, not
+  documentation-based).
+
+### Verification targets
+
+- Grep for `useState(` call sites; for each, trace the value's origin (is it
+  seeded from `getQuery`, `readBody`, or an API response that echoes
+  user-submitted content?) and its eventual consumers (any `v-html` binding, any
+  `innerHTML`/`dangerouslySetInnerHTML`-equivalent sink).
+- Grep for `definePayloadReducer(`/`definePayloadReviver(` and read the custom
+  serialization logic for any manual string concatenation that lands in
+  rendered HTML.
+- Apply the same sanitizer-on-exact-path standard as any `v-html` review: a
+  sanitizer existing elsewhere in the codebase does not clear a specific traced
+  path (same principle as Vue's own `v-html` guidance).
+
+### Fix sketch
+
+```vue
+<script setup>
+import DOMPurify from 'dompurify'
+
+// comment.body is user-submitted content that round-tripped through
+// useAsyncData's payload cache — the payload is the transport, this
+// sanitizer call is what actually clears the finding.
+const { data: comment } = await useAsyncData('comment', () => $fetch(`/api/comments/${id}`))
+const safeBody = computed(() => DOMPurify.sanitize(comment.value?.body ?? ''))
+</script>
+
+<template>
+  <div v-html="safeBody" />
+</template>
+```
+
+## Part 3 — missing security response headers
+
+### What people get wrong
+
+The naive assumption is:
+
+> "Nuxt is a modern framework, so it must ship secure headers (CSP, X-Frame-Options,
+> etc.) by default."
+
+Wrong. Context7 confirms the mechanisms available, but not that any are
+enabled by default:
+
+- `routeRules` in `nuxt.config.ts` supports a `headers` property that "allows
+  adding specific HTTP headers to sections of your site" (`documentation-based`,
+  `/websites/nuxt_4_x`, "Hybrid Rendering > Route Rules"), and a documented
+  example shows `cors: true` adding CORS headers to an API route glob, further
+  customizable via the same `headers` property. Nothing in the confirmed docs
+  shows CSP/X-Frame-Options/HSTS enabled by default — these must be configured
+  explicitly per route or globally (`'/**': { headers: { ... } }`).
+- `useResponseHeader(name)` is a documented composable for setting any server
+  response header from within pages, components, or plugins, including on a
+  per-page basis (`documentation-based`, `/websites/nuxt_4_x`,
+  `useResponseHeader` API reference).
+- A dedicated community security module (commonly referred to as
+  `nuxt-security`) exists to apply a curated default header set (CSP, HSTS,
+  X-Frame-Options, and related hardening) in one step. Context7's Nuxt-core
+  documentation set (`/websites/nuxt_4_x`, `/websites/nuxt_3_x`) does not itself
+  document this third-party module's API or defaults — treat any specific claim
+  about its default header values as `inference`, not `documentation-based`;
+  confirm its presence/config directly in the repo (`nuxt.config.ts` `modules`
+  array and any `security:` config block) rather than asserting what it does
+  from memory.
+
+### Non-negotiable design rules
+
+1. **Absence of any header-setting mechanism is the finding, not the absence of
+   a specific module.** Check for *any* of: a `routeRules` block with a
+   `headers` entry covering the routes in scope, a `nuxt-security`-style module
+   in the `modules` array, or middleware/plugin code calling
+   `useResponseHeader(...)`. If none exist anywhere in the app, and the app
+   handles authentication, forms, or third-party embeds, flag MEDIUM-to-HIGH
+   depending on what the app does (rubric item 8).
+2. **Partial coverage is a real, narrower finding.** If headers are set for `/`
+   but not for `/admin/**` or `/api/**`, do not report "headers exist, fine" —
+   report the specific gap, citing the routeRules glob(s) that are covered vs.
+   not.
+3. **Do not flag an app that already has a working mechanism covering the
+   routes in scope** (rubric item 15) — verify the glob pattern's actual
+   coverage before crediting it, since a `'/blog/**': { headers: {...} }` rule
+   does not cover `/admin/**` or the site root.
+
+### Verification targets
+
+- Grep `nuxt.config.*` for `routeRules` and inspect every entry for a `headers`
+  key; note which route globs are covered.
+- Grep `nuxt.config.*` `modules` array for a security-module name (e.g.,
+  `nuxt-security`) and read its adjacent config block if present.
+- Grep the codebase for `useResponseHeader(` calls in plugins/middleware/pages.
+- Cross-reference coverage against the app's actual surface (auth pages,
+  forms, admin routes, embedded third-party widgets) to size the severity.
+
+### Fix sketch
+
+```ts
+// nuxt.config.ts
+export default defineNuxtConfig({
+  routeRules: {
+    '/**': {
+      headers: {
+        'X-Frame-Options': 'DENY',
+        'X-Content-Type-Options': 'nosniff',
+        'Content-Security-Policy': "default-src 'self'",
+      },
+    },
+  },
+})
+```