/sota-web-frameworks

name: sota-web-frameworks
description: >-
  State-of-the-art engineering rules (2026) for the JavaScript SSR meta-frameworks:
  React 19 + Next.js (App Router, React Server Components, Server Actions) and Vue 3 +
  Nuxt 4 (Nitro server routes, composables) — plus the cross-cutting concerns of
  server rendering: hydration correctness, SSR state serialization, the server/client
  trust boundary, and framework-specific security and CVEs. Use when building or
  auditing any React/Next or Vue/Nuxt app — components, RSC/client boundaries, Server
  Actions or Nitro routes, data fetching and caching, hydration mismatches, SSR/SSG/ISR
  strategy, or framework CVE exposure. Complements sota-javascript-typescript,
  sota-frontend-design, sota-code-security, and sota-performance. Trigger keywords:
  React, Next.js, App Router, React
  Server Components, RSC, Server Actions, use client, use server, Vue, Nuxt, Nitro,
  Pinia, composable, script setup, SSR, hydration, hydration mismatch, use cache, PPR,
  ISR, proxy.ts, middleware, useFetch, useState, runtimeConfig, CSP nonce, devalue.

SOTA Web Frameworks (2026)

Purpose

This skill encodes the 2026 state of the art for the two dominant JavaScript SSR stacks — **React + Next.js** and **Vue + Nuxt** — and the server-rendering concerns they share. It is deliberately framework-specific: the traps that matter here (the RSC server/client boundary, Server Actions as public endpoints, hydration mismatches, SSR state leaking across requests, `runtimeConfig`/`NEXT_PUBLIC_` secret boundaries) do not exist at the plain-language level.

Two modes:

• **BUILD** — writing or modifying components, routes, and data-fetching to this standard.
• **AUDIT** — reviewing an existing app and reporting findings.

Read SKILL.md fully; load `rules/*.md` on demand per the index below. **Verify every version/CVE claim at use time** — this file's facts were primary-sourced 2026-07 but framework security moves weekly (see the 2025-12 React Server Components RCE).

Scope boundaries (what lives elsewhere)

This skill stacks *on top of* the general skills — load them together, don't duplicate:

• **`sota-javascript-typescript`** — strict `tsconfig`, type design, promises,

Node hardening, npm supply chain. The *language*; this skill is the *framework*.

• **`sota-frontend-design`** — visual design, layout, components-as-UX, WCAG 2.2

accessibility, motion. This skill covers component *engineering*, not *design*.

• **`sota-code-security`** — generic XSS/CSRF/SSRF/authn/authz/crypto theory. This

skill covers the *framework-specific* expression of those (RSC data exposure, Server Action authz, `v-html`, next/image SSRF).

• **`sota-performance`** rules/06 — Core Web Vitals, bundle budgets, image/font

loading. This skill covers render-strategy choice (SSR/SSG/ISR/PPR) and hydration.

• **`sota-api-design`** — REST/GraphQL contract design for the routes themselves.

BUILD mode

1. **Establish context first.** Read `package.json` for the exact React/Next or Vue/Nuxt majors and the render mode in use (App vs Pages Router; Nuxt SSR vs `ssr: false`). Match the project's baseline — no Server Actions on a Pages-Router app, no `defineModel` below Vue 3.4. Confirm the versions are supported and patched against the CVE tables in `rules/03`/`rules/05`. (`rules/01`) 2. **Default to the current idiom:** React function components + hooks (let the React Compiler memoize — don't hand-write `useMemo` everywhere); Vue Composition API with `<script setup>`. Server Components by default in Next App Router, `"use client"` only at the leaves that need interactivity. (`rules/02`, `rules/04`) 3. **The server/client boundary is a security boundary, not just a perf one.** Every prop crossing server→client is serialized into the HTML/RSC payload and is public. Authorization lives *next to the data* (a Data Access Layer / validated server route), never only in middleware or a layout. (`rules/03`, `rules/07`) 4. **Treat every Server Action and Nitro route as a public, unauthenticated HTTP endpoint** until it validates input and checks authz itself — even if it looks internal or is never imported. (`rules/03`, `rules/05`, `rules/07`) 5. **Get hydration right by construction:** deterministic render (no `Date.now()`, `Math.random()`, or `window` in render), stable IDs via `useId`, SSR-safe shared state (`useState`/per-request instances, never module-level refs). (`rules/06`) 6. **Serialize SSR state safely** (framework serializer or escaped JSON, never naked `JSON.stringify` into `<script>`) and **wire CSP** (nonce or hash) knowing it forces dynamic rendering in Next. (`rules/06`, `rules/07`) 7. **Tests accompany code** (`sota-testing`): component tests plus at least one test that exercises the server/client boundary or a server route's authz.

AUDIT mode

1. **Fingerprint + patch-check first.** Pin exact framework/loader versions from the lockfile and diff them against the CVE tables in `rules/03` and `rules/05`. An unpatched React2Shell (CVE-2025-55182) or middleware bypass (CVE-2025-29927) is CRITICAL on its own, before any code is read. 2. **Trace the trust boundary.** Grep `"use client"`/`"use server"`, `defineProps`, `runtimeConfig`, `NEXT_PUBLIC_`/`NUXT_PUBLIC_`; find where server data crosses to the client and where authz is enforced. Middleware/layout-only authz is a finding. 3. **Run each relevant rules file's Audit checklist** (grep-driven), then read for design: hydration determinism, SSR state isolation, caching of personalized pages. 4. **Verify every finding** — a `v-html` fed a constant is not XSS; a Server Action that re-checks the session is not IDOR. Note mitigations already present.

Severity conventions

| Severity | Meaning | Examples | |---|---|---| | CRITICAL | Exploitable now / RCE / data loss | Unpatched RSC deserialization RCE; middleware-bypass auth on the only authz layer; secret in `NEXT