# Nextjs App Router Data Fetching Review > Statically review Next.js App Router Server/Client Component boundaries and Server Action data mutations for correct data-fetching placement, bundle-leak risk, and authorization-trust integrity, escalating client-trusted authorization to a security finding rather than a style note. - Skill: `vincentchuwaichow/nextjs-app-router-data-fetching-review` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add vincentchuwaichow/nextjs-app-router-data-fetching-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/vincentchuwaichow/nextjs-app-router-data-fetching-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: VincentChuWaiChow (https://skillmd.com/u/vincentchuwaichow) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/vincentchuwaichow/nextjs-app-router-data-fetching-review --- # Next.js App Router Data Fetching Review ## Purpose Review the Server Component / Client Component boundary (`'use client'` placement and its import graph) and Server Action (`'use server'`) authorization logic in a Next.js App Router codebase, without re-litigating rendering mode, `fetch()` caching, or component decomposition in every response. This skill exists so bundle-leak risk and Server Action authorization-trust defects stay the focus, and so those adjacent concerns stay out of scope. ## When to use Use this skill when the user asks to: - review a `'use client'`/`'use server'` boundary in a diff or PR, - determine whether a Server Action correctly authorizes its caller, - investigate a report that server-only code or a secret appears to be reaching the browser bundle. Do not use this skill for: - pure UI/styling changes with no data-fetching or boundary change, - Pages Router API routes (`pages/api/*`) — different security model, not Server Actions; use general API-route review instead, - rendering-mode selection (static/ISR/dynamic) or `fetch()` cache-configuration review — that is `nextjs-rendering-caching-review`, - component decomposition or state-placement review with no boundary or Server Action involved — that is `react-component-architecture-review`. ## Context7 Documentation Protocol - Resolve `/vercel/next.js` with `resolve-library-id` before citing any Server Component restriction or Server Action security claim. - Before asserting what is or is not safe to import into a Client Component, or what a Server Action must re-verify, read the repo's `package.json` to confirm the installed Next.js major version, then call `query-docs` scoped to that version for "Server Actions security" and "Server Components restrictions." The exact bundling/serialization rules and the availability of the Taint API (`experimental_taintObjectReference` / `experimental_taintUniqueValue`, gated behind `experimental.taint` in `next.config`) are version-specific. - 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 - Server Components are the App Router default; `'use client'` is an opt-in boundary marker at the top of a file, above imports. Once a file is marked `'use client'`, everything it imports and directly renders is included in the client bundle — trace that import graph, do not eyeball the single file. - Treat a Client Component's import graph reaching a server-only module (a DB/ORM client, a module reading a non-`NEXT_PUBLIC_`-prefixed env var, filesystem access, or any module importing `server-only`) as a HIGH-severity bundle-leak finding. This is the hard security gate for this skill's boundary half. - A Server Action's arguments (including `FormData`) are fully client-controlled, even though the function body runs on the server. Treat any Server Action that derives its authorization decision from its own input parameters or `FormData` — instead of re-deriving identity from the server-side session (`cookies()`, an `auth()`/session helper) — as a HIGH-severity Broken Access Control finding (OWASP Top Ten A01), not a style note. - Page-level or layout-level authentication/authorization checks do not extend into a Server Action invoked from that page. Each Server Action must independently re-verify session and, for resource-scoped mutations, ownership/role — absence of that re-check is a defect even if an upstream page already checked auth. - Do not recommend converting a Client Component to a Server Component without first checking it doesn't rely on browser-only APIs, local state, effects, or event handlers — that breaks functionality, it does not fix a boundary defect. - Do not flag every `'use client'` directive as a problem. Only flag it when the boundary is placed higher than the smallest interactive leaf needs, or when its import graph leaks server-only code. - Never execute, build, or run application code as part of this review; this is a static-review skill (Read/Grep/Glob only). - Treat any hardcoded API key, token, session secret, or credential found in a Server Action, Client Component, or example data as a HIGH-severity finding requiring immediate escalation, not a boundary note. ## 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 bundle-leak trace method, the authorization decision tree, and the required output shape. - [OWASP A01 — Broken Access Control](references/owasp-a01-broken-access-control.md) — load only when a Server Action authorization finding is present, to ground the finding's severity and framing. ## Response minimum Return, at minimum: - per-boundary table (`'use client'` file, traced import-graph leak or clean, evidence file:line), - per-Server-Action table (action, authorization source used, verdict), - ranked findings with file:line, risk class, and fix, - the Next.js major version the claims were verified against, - verdict: approve / approve-with-notes / block, - evidence level and open questions.