Review Nuxt 3/4 full-stack code — nuxt.config.ts, composables/, plugins/,\nserver/api/, server/routes/, server/middleware/, and templates using\nuseState/v-html — for five defect classes Nuxt's own documentation and its\nlong-lived Nitro server model make security-critical: (a) private secrets placed\nunder runtimeConfig.public (or fed by NUXT_PUBLIC_* env vars) so they ship in the\nclient bundle, (b) useState/module-scope reactive or mutable state leaking across\nrequests in Nitro's single long-lived process, (c) server-route SSRF via\n$fetch/ofetch to a user-controlled URL and blind forwarding of\nuseRequestHeaders()/credentials, (d) NuxtPayload/useState data reaching an\nunsanitized render sink (XSS), and (e) missing security response headers\n(routeRules headers, the nuxt-security module, useResponseHeader). This\nskill exists so the review stays anchored to these five documented, structural\ndefect classes instead of drifting into a general \"Nuxt code review.\"
Use this skill when the user asks to:
\nnuxt.config.ts runtimeConfig/routeRules block for\nsecret-exposure or missing-header risk,server/api/* or server/routes/* handler that calls out to another\nservice ($fetch/ofetch/event.$fetch),useState/payload value rendered with v-html is safe,Do not use this skill for:
\nvue-composition-api-architecture-review instead,entry-server.js, raw @vue/server-renderer\nusage) with no Nuxt-specific API involved — use vue-ssr-security-review instead,runtimeConfig/server//useState surface — use\nvue-state-store-security-review or vue-router-navigation-security-review\ninstead,/websites/nuxt_4_x (primary; Nuxt 4 prose docs) and\n/websites/nuxt_3_x (Nuxt 3 prose docs) before citing any runtimeConfig,\nuseState, $fetch/event.$fetch/useRequestFetch/useRequestHeaders,\npayload/devalue, routeRules, or useResponseHeader behavior as fact. Both are\nNuxt's own documentation site content mirrored into Context7 — treat matches from\neither as documentation-based.package.json's nuxt dependency)\nbefore assuming version-specific defaults; the APIs this skill covers are stable\nacross 3/4, but state which major was confirmed when citing a claim.nuxt-security module's exact default header set and\nconfiguration surface is not covered by Nuxt's own Context7-indexed docs —\nnever state a specific default for it as documentation-based. Confirm its\npresence/config by reading the repo's nuxt.config.ts directly, and label any\nclaim about its behavior inference unless corroborated by the module's own\ndocumentation (not currently in scope for this skill's Context7 grounding).inference.official_docs URLs in this skill's\nmetadata.json and label the claim documentation-based, unverified against current release.references/ssrf-payload-and-response-headers.md, Part 3). Do not\ndowngrade a structural runtimeConfig exposure, cross-request state leak, SSRF\npath, or payload-XSS trace to informational because it has not been observed\nexploited yet.runtimeConfig key by its actual nesting (top-level = private,\nunder public = client-exposed) — never by variable name alone. A key named\napiSecret sitting inside public is exposed; a key named baseUrl sitting\noutside public is still private and not itself a finding.useState/ref/reactive/mutable objects are at\nrisk; immutable constants are not), and reachability from server-rendered code\n(a declaration no server-rendered path ever touches is not a finding in this\nscope).$fetch/ofetch/event.$fetch call in a server route as safe\nfrom SSRF just because it \"looks like an API call\" — trace the destination URL\nto its origin and confirm either a hardcoded host or an explicit allowlist check\nbefore the request fires.event.$fetch's default forwarding,\nuseRequestHeaders(...), or manual header spreading) as safe just because\nNuxt documents the mechanism — the mechanism existing is not the same as its\nuse being scoped to only the headers actually needed and only trusted\ndestinations.useState/payload value reaching a v-html binding unless a\nnamed sanitizer call is visibly present on that exact traced path — a sanitizer\nexisting elsewhere in the codebase does not clear this bar.routeRules glob (or module\nconfig) actually covers the routes in scope before crediting it.Load these only when needed:
\nnuxt.config.ts's runtimeConfig block, NUXT_PUBLIC_*\nenv vars, or useState/module-scope reactive/mutable declarations reachable\nfrom server-rendered code.server/api/server/routes handler's outbound\n$fetch/ofetch/event.$fetch/useRequestFetch calls, a useState/payload\nvalue that renders somewhere, or routeRules/security-module configuration.Return, at minimum:
\nruntimeConfig/routeRules blocks, module-scope declarations, server\nroutes, and/or template bindings in scope,runtimeconfig-exposure / cross-request-state-pollution / ssrf /\ncredential-forwarding / payload-xss / missing-security-headers), the\nconcrete data-flow trace, and a fix sketch matching Nuxt's documented pattern,useState/payload → render-sink finding, an explicit statement of\nwhether a sanitizer call is present on the traced path — never approve on the\nassumption one exists elsewhere,repo evidence, documentation-based, or\ninference), with structural risk findings explicitly labeled as structural\nrisk, not as confirmed-exploited,