z3tz3r0 5108b20954
feat(rules): add vue and nuxt rule sets (#2250)
* feat(rules): add vue and nuxt rule sets

Add rules/vue/ and rules/nuxt/, each with the standard 5-file layout (coding-style, hooks, patterns, security, testing) that extends common/, following the Adding a New Language convention in rules/README.md.

Vue rules reference the frontend-patterns and vite-patterns skills. Nuxt rules reference the nuxt4-patterns and vite-patterns skills. Content is concise (1.5 to 4 KB per file) since rules load as always-on context.

* fix(rules): address PR review on vue and nuxt rule sets

- nuxt/coding-style: generalize the srcDir-override note (drop project-specific 'this repo' phrasing so it is correct for any Nuxt project).

- vue/hooks: add **/*.ts and **/*.tsx to paths so the lint/typecheck guidance loads when editing composables and stores.

- nuxt/hooks: add **/*.vue to paths (covers pages/layouts/components) and wrap nuxi typecheck in a timeout, mirroring web/hooks.md.

- nuxt/security: tighten the /security-review auto-trigger scope to external fetch, credential handling, and sensitive mutations, with examples.

- nuxt/testing: correct 'Vitest-only' to note built-in Playwright E2E, and drop the @nuxt/test-utils version pin.

- README: register vue and nuxt in the structure tree and install examples.

Skipped: 'X specific' -> 'X-specific' hyphenation (all existing rule sets use the unhyphenated form, changing only vue/nuxt would be inconsistent); repeating the 80%/TDD mandate in nuxt/testing (already inherited from common/testing.md).
2026-06-15 14:01:38 -04:00

2.5 KiB

paths
paths
**/nuxt.config.*
**/app.config.*
**/server/**/*.ts

Nuxt Security

This file extends common/security.md with Nuxt specific content.

runtimeConfig public vs private

  • Root runtimeConfig keys are server-only. runtimeConfig.public serializes into EVERY page payload (client-visible).
  • Secrets go at root only. Never put secrets in app.config.ts or runtimeConfig.public, both ship to the client bundle.
  • Official warning: "Be careful not to expose runtime config keys to the client-side by either rendering them or passing them to useState."

Server-route input validation

  • Use h3 validating readers. Do NOT trust raw readBody / getQuery / getRouterParam.
    • readValidatedBody(event, schema) validates the body.
    • getValidatedQuery(event, schema) validates the query.
    • getValidatedRouterParams(event, schema) validates route params.
  • All accept a validation function or a Zod schema and throw on failure.

SSR payload leakage

  • Anything in useState, useFetch / useAsyncData results, or runtimeConfig.public is serialized into the client payload. Never write a secret into those.
  • Use useServerSeoMeta for server-only meta with no client cost.
  • Nuxt does NOT auto-attach the incoming user's cookies to outbound server-side $fetch.
  • Forward explicitly with useRequestFetch() (cleanest, pre-bound to request headers) or useRequestHeaders(['cookie']).
  • Relay a backend Set-Cookie to the browser via $fetch.raw + appendResponseHeader(event, 'set-cookie', ...).
  • socket.io is client-only (.client.ts plugin), never SSR.

SSRF on server $fetch

  • Server routes run with full network egress. Never pass user-controlled input directly into a server-side $fetch URL or host.
  • Validate the param first (h3 utilities above), allowlist the target, pin to runtimeConfig.public.apiBase, reject user-supplied absolute URLs.
  • Auto-trigger /security-review only for routes that make external network requests (server $fetch), handle auth tokens or credentials, or perform sensitive mutations or authorization checks. Examples: SSRF-prone proxy endpoints, token exchange or password reset, admin actions. Skip benign read-only routes that only accept validated query params.

Reference