@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.1

package/skills/frontend/nextjs-rendering-caching-review/references/isr-reference.md

@@ -0,0 +1,45 @@
+# ISR reference (generateStaticParams + revalidate)
+
+Use this reference only for App Router routes using `generateStaticParams` combined with a time-based `revalidate` export or `next: { revalidate }` fetch option. Do not apply this to Pages Router `getStaticProps`/`getStaticPaths` — that is a different, legacy API surface; if you encounter it, note it as out-of-scope for this skill rather than translating App Router guidance onto it.
+
+## What people get wrong
+
+The naive story is:
+
+> `revalidate: 60` means the page is rebuilt every 60 seconds, so pick a number and move on.
+
+Wrong. `export const revalidate = 60` (or `next: { revalidate: 60 }` on the underlying `fetch()`) means: Next.js will attempt to re-generate the page in the background **at most once every 60 seconds, and only when a request comes in** after that window — it is not a background cron. Until regeneration completes, the **stale** cached version continues to be served (stale-while-revalidate), not a loading state and not a 404. If regeneration throws an uncaught error, Next.js does **not** invalidate the currently-shown page; it keeps serving the last successfully generated version and retries on the next request. This error-handling behavior matters for the review: a `revalidate`-backed route that silently swallows fetch errors can serve indefinitely-stale data without ever surfacing a failure, because the fallback is "keep serving the old page," not "fail loudly."
+
+## Officially grounded shape
+
+- `generateStaticParams` defines which dynamic-segment values (`params`) get prerendered at build time; segments not returned by it are generated on first request (or 404, depending on `dynamicParams` config) and then cached per the route's `revalidate` value.
+- `export const revalidate = N` sets the route-level regeneration interval in seconds. A `fetch()` call inside the route can independently set its own `next: { revalidate: N }` — the **effective** revalidation window for the route is the **minimum** of the route-level export and any fetch-level values that feed the rendered output. Do not evaluate only the route-level export and ignore a shorter fetch-level value (or vice versa).
+- On-demand revalidation (`revalidatePath`, `revalidateTag`) supersedes the time-based window — it forces the next request to regenerate regardless of how much of the interval has elapsed. A route using only on-demand revalidation with no `revalidate` export is valid (fully static until an explicit invalidation call) — do not flag the absence of a time-based `revalidate` as a defect when on-demand invalidation is present and wired to the actual mutation path.
+
+## Non-negotiable design rules
+
+1. **Trace the effective revalidation window to the shortest contributing value.** If the route export says `revalidate = 3600` but one `fetch()` inside it uses `next: { revalidate: 60 }`, the route effectively refreshes at the 60-second cadence for that data. Flag a review that only cites the route-level export as incomplete.
+
+2. **Confirm error handling does not silently extend staleness beyond intent.** If `getData()` swallows a non-2xx response (e.g. returns a default/cached object instead of throwing), a backend outage will not trigger the "keep serving last good page and retry" fallback correctly — verify the fetch call surfaces failures (throws or returns a non-ok response Next.js can detect) rather than masking them.
+
+3. **Verify `generateStaticParams` coverage matches the actual param space, or that `dynamicParams` is deliberately configured.** Undercovering high-traffic params with `dynamicParams: false` produces 404s for legitimate paths; overcovering a huge param space with build-time generation can blow up build time — this is a build-cost finding, not correctness, but should still be flagged as MEDIUM if extreme.
+
+4. **Do not apply ISR guidance to per-user data.** ISR caches are shared across all requests to that path/param combination. If the page under `generateStaticParams` renders user-specific content (e.g., `/dashboard/[userId]` returning that user's private data) and relies on route-level `revalidate` without a `no-store`/dynamic escape hatch for the personalized parts, this is the cross-user leakage pattern from SKILL.md's hard security gate — escalate to HIGH, not a normal ISR tuning note.
+
+## Minimal safe verification flow
+
+1. Confirm the Next.js major version (ISR semantics referenced here are for App Router, current stable behavior; verify no `use cache`/Cache Components migration has changed the model — see SKILL.md's Context7 protocol).
+2. Locate every `revalidate` export and every `next: { revalidate }` fetch option in the route; compute the effective window.
+3. Confirm `generateStaticParams` scope is intentional (full enumeration vs. partial + `dynamicParams`).
+4. Confirm fetch error handling doesn't mask backend failures.
+5. Confirm no per-user data flows through a route relying on shared ISR caching without a scoped escape hatch.
+
+## When to push back
+
+Push back if the user asks for:
+
+- a single global `revalidate` value applied uniformly "to keep it simple" across routes with very different freshness requirements — that produces either unnecessary staleness or unnecessary regeneration load,
+- ISR applied to a route serving authenticated, per-user data with no scoped `no-store`/dynamic fetch for the personalized parts,
+- removing error handling from the data-fetch function "to simplify the code" — that removes the safety net that keeps a broken backend from ever surfacing as a build/render failure.
+
+Those are not simplifications. They trade away either freshness guarantees or the leak/error-visibility safety net ISR depends on.

package/skills/frontend/nextjs-rendering-caching-review/references/workflow-and-output.md

@@ -0,0 +1,85 @@
+# Review workflow and findings contract
+
+Use this reference for the full rendering/caching review procedure and the required output shape.
+
+## What people get wrong
+
+The naive story is:
+
+> Static is faster, dynamic is safer for personalized data, so just eyeball the route and guess.
+
+Wrong. Rendering mode and cache configuration are decided per `fetch()` call, not just per route — a nominally "static" route can still leak per-user data if one of its `fetch()` calls defaults to `force-cache` on a response that embeds session-scoped content. Conversely, a route marked `force-dynamic` "to be safe" pays full per-request render cost even when only one of its five `fetch()` calls actually needs freshness. The review has to operate at both the route level and the individual `fetch()`-call level, and it has to separate two independently-varying axes: **staleness** (is this data fresh enough) and **audience** (is this response safe to share across users).
+
+## Workflow
+
+1. **Confirm the Next.js major version and deployment target**
+   - Read `package.json` for the exact Next.js version. Read hosting config (`next.config.js`, deployment docs, CI) for Vercel vs self-hosted.
+   - Do not proceed to assert a caching default before this step; Next 14 and Next 15 have different `fetch()` defaults (see Context7 Documentation Protocol in SKILL.md).
+
+2. **Classify each route segment's rendering mode**
+   - **Static**: no `dynamic` export or `dynamic = 'auto'`/`'force-static'`, no dynamic APIs (`cookies()`, `headers()`, `searchParams` read at render), and no `fetch()` call configured `no-store` or tagged with per-request freshness.
+   - **ISR**: has `export const revalidate = <seconds>`, or at least one `fetch()` using `next: { revalidate: N }`, combined with `generateStaticParams` for dynamic segments.
+   - **Dynamic**: has `export const dynamic = 'force-dynamic'`, uses `cookies()`/`headers()`/uncached `searchParams`, or has a `fetch()` using `cache: 'no-store'` that determines the response.
+   - Record the exact evidence (file:line) backing each classification. Do not infer mode from route naming or folder structure.
+
+3. **Extract every `fetch()` call's cache configuration**
+   - Note `cache: 'force-cache' | 'no-store'`, `next: { revalidate, tags }`, and whether the option is explicit or relying on the version's default.
+   - Cross-reference against the confirmed Next.js major (step 1) to know what "no option specified" actually means for that call.
+
+4. **Cross-reference data sensitivity against cache scope**
+   - For each `fetch()` call, determine whether the fetched or returned data is per-user/session-scoped: does it forward an `Authorization` header, a session cookie, or a user ID from `cookies()`/`headers()`/route params into the request or the response shape?
+   - If yes, and the call uses the default/`force-cache` behavior with no user-scoped cache key or tag differentiating it per user, this is a **leakage candidate** — proceed to the decision tree below.
+
+5. **Check `revalidateTag`/`revalidatePath` scope**
+   - Confirm each invalidation call targets exactly the tag/path that changed. A `revalidateTag('posts')` call fired from an endpoint that only mutates one post's title is over-broad if other tags exist per-entity; a call that never fires after the relevant mutation is under-invalidation (stale-data risk).
+
+6. **Produce ranked findings**
+   - Order by blast radius: cross-user data leakage first (always HIGH, security sign-off required), then correctness/staleness defects, then avoidable performance cost (unnecessary `force-dynamic`), then lower-severity notes.
+
+## Decision tree
+
+- `fetch()` call includes `Authorization`, forwards a session cookie, or otherwise returns per-user data **AND** uses the version's default/`force-cache` behavior with no `no-store` and no user-scoped tag/key → **HIGH: cross-user leakage risk.** Escalate per SKILL.md's hard security gate — this is a security finding, not a caching-strategy note.
+- Route needs freshness within N seconds and currently has no `revalidate`/tag strategy → recommend ISR with the appropriate `revalidate` value or `next: { revalidate: N }` on the relevant `fetch()` calls. Do not default to blanket `force-dynamic`.
+- Route is fully static content but marked `force-dynamic` (or has an unnecessary `no-store` fetch) → flag as avoidable TTFB/hosting cost; recommend the minimal-scope fix (fix the one `fetch()` call, not the whole route, unless every call genuinely needs it).
+- `revalidateTag`/`revalidatePath` scope is broader than the mutation that triggered it → flag as over-invalidation (cache-hit-rate/cost regression). Scope narrower than the mutation → flag as stale-data risk.
+
+## Output contract
+
+Return:
+
+1. Next.js major version and deployment target confirmed (or explicitly noted as unconfirmed)
+2. Per-route rendering-mode table: route | mode | evidence (file:line) | justification
+3. Ranked findings, each with:
+   - file:line evidence
+   - risk class (cross-user leakage / staleness / avoidable dynamic cost / over- or under-invalidation)
+   - concrete fix, scoped to the narrowest sufficient change
+   - severity (HIGH / MEDIUM / LOW)
+   - evidence level (`repo evidence`, `documentation-based`, `inference`)
+4. Verdict: approve / approve-with-notes / block
+5. Open questions or explicitly out-of-scope items (e.g. Pages Router files encountered, or unconfirmed deployment target)
+
+## Validation gates
+
+- Every caching-default claim states the Next.js major version it was verified against.
+- Every cross-user-leakage finding identifies exactly which data field is at risk and why the current cache configuration would serve it to another user — not just "this looks user-specific."
+- No finding assumes Vercel-specific cache behavior (e.g. Data Cache persistence across deployments, on-demand ISR via the Vercel API) for a self-hosted deployment without confirming the deployment target first.
+- No leakage finding is downgraded from HIGH severity for "code cleanliness" reasons; the security-notes hard gate applies regardless of how minor the fix looks.
+
+## Common failure modes
+
+- Assuming Next 13/14 caching defaults (`fetch()` cached by default) on a Next 15+ codebase, or vice versa — always version-check first.
+- Treating all dynamic rendering as a defect, ignoring that some routes genuinely require per-request data.
+- Conflating Request Memoization (dedup within one render pass) with the Data Cache (cross-request persistence) — a memoized call is not a caching-leakage risk across users because it does not persist past the single render.
+- Recommending route-wide `force-dynamic` as the default fix for a single-`fetch()` leakage finding, incurring unnecessary TTFB cost on the rest of the route.
+
+## Adversarial checklist
+
+Before finalizing a finding, answer these:
+
+- Does any `fetch()` call returning per-user data lack an explicit `no-store` or a user-scoped cache tag/key?
+- Is the caching-default claim matched to the actual Next.js major version in `package.json`, not assumed from general familiarity with "Next.js"?
+- Does a `revalidateTag`/`revalidatePath` call risk invalidating (or under-invalidating) data unrelated to, or needed by, the change that triggered it?
+- Is a route's dynamic classification actually required by real per-request data, or could it be static/ISR with equivalent correctness and lower cost?
+- Is the deployment target (Vercel vs self-hosted) confirmed before citing a platform-specific cache behavior?
+
+If any answer is "not sure," lower the finding's confidence and label the evidence level accordingly — do not present it as a confirmed defect, except for leakage findings with clear file:line evidence of per-user data plus default/cached fetch behavior, which stay HIGH regardless.

package/skills/frontend/nextjs-server-security-review/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: nextjs-server-security-review
+description: Statically review Next.js middleware, Server Actions, next.config.js, and environment-variable files for four documented server-side defect classes -- middleware matcher exclusions that silently skip auth on Server Functions, Server Actions missing allowedOrigins CSRF protection, secrets leaked via NEXT_PUBLIC_ prefixes, and SSRF/open-redirect via dangerouslyAllowLocalIP or unvalidated rewrite destinations.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-03"
+  category: security
+---
+
+# Next.js Server Security Review
+
+## Purpose
+
+Review Next.js middleware (`middleware.ts`/`.js`), Server Actions, `next.config.js`, and environment-variable files for the concrete server-side defect classes Next.js's own documentation calls out directly: middleware `matcher` exclusions that silently skip authorization for Server Functions, Server Actions missing `allowedOrigins` CSRF protection, secrets accidentally exposed to the client via a `NEXT_PUBLIC_` prefix, and server-side request forgery / open-redirect risk via `dangerouslyAllowLocalIP` or an unvalidated rewrite destination. This skill exists so the review stays anchored to these documented defect classes instead of drifting into a general "Next.js code review" of component architecture, data fetching patterns, or styling.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review `middleware.ts`/`middleware.js` and its `matcher` configuration for authorization gaps,
+- assess whether a Server Action is protected against CSRF, or whether `next.config.js`'s `serverActions.allowedOrigins` is configured correctly for a reverse-proxy or multi-zone deployment,
+- audit `.env`/`.env.production` files or any `process.env.NEXT_PUBLIC_*` usage for accidental secret exposure to the client bundle,
+- review `next.config.js` image configuration (`images.dangerouslyAllowLocalIP`) or `rewrites()`/`NextResponse.rewrite()` usage for SSRF or open-redirect risk,
+- perform a pre-launch security review of a Next.js server surface (middleware, Server Actions, config, env files).
+
+Do not use this skill for:
+
+- client-only React component logic with no middleware, Server Action, config, or environment-variable surface in scope — there is no server-side sink for this skill to review,
+- general Next.js performance, data-fetching-pattern, or App Router/Pages Router migration review with no security angle,
+- a bug that requires live traffic reproduction (actually triggering a CSRF request cross-origin, actually confirming an SSRF callback from a deployed image optimizer) to prove exploitation — static analysis proves the structural risk, not that it has already been exploited in production.
+
+## Context7 Documentation Protocol
+
+- Resolve the Next.js library ID with `resolve-library-id` (matched result: `/vercel/next.js`) before citing any middleware, Server Actions, environment-variable, or `next.config.js` behavior claim.
+- `/vercel/next.js` is a high-reputation source covering authentication, middleware, Server Actions, environment variables, and `next.config.js` security patterns directly from the framework's own docs and source. Use `query-docs` against it to confirm exact option names (`serverActions.allowedOrigins`, `images.dangerouslyAllowLocalIP`) and documented behavior (`NEXT_PUBLIC_` inlining, matcher exclusion semantics) before writing a finding.
+- Read `package.json` first to confirm the Next.js major version and whether the app uses the App Router or Pages Router — `experimental.serverActions` configuration, middleware `matcher` conventions, and `NextResponse.rewrite()` APIs have shifted across major versions; do not apply App Router API names to a Pages Router codebase or vice versa.
+- 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
+
+- All four defect classes in this skill's scope default to HIGH severity. This is a security-scoped skill: do not downgrade a middleware-matcher authorization gap, a missing CSRF allowlist, a leaked secret, or a structural SSRF/open-redirect path to MEDIUM just because it has not been observed exploited yet — the risk is in the structure, not in whether someone has already hit it.
+- Trace every finding to a concrete file:line and a concrete data-flow path. A finding that says "this middleware might not protect everything" or "this env var might leak" without showing the specific `matcher` pattern, the specific `serverActions` config, or the specific variable declaration is not a valid finding — it is a guess.
+- Never accept a middleware `matcher` as sufficient authorization coverage in isolation. A `matcher` whose negative-lookahead pattern excludes a path (e.g. `/((?!api|_next).*)`) means middleware — and any auth check it performs — never runs for that excluded path; a Proxy matcher that excludes a path also skips Server Function calls on that path. Confirm the excluded path's own handlers (Server Actions, Route Handlers) independently verify the session themselves.
+- Never approve a `next.config.js` with a `serverActions` block configured for a reverse-proxy, multi-zone, or otherwise cross-origin deployment unless `allowedOrigins` is explicitly present in that same block. Next.js's default CSRF protection compares the Server Action request's `Origin` header to the `Host` header and rejects mismatches — a deployment where those two headers legitimately differ (reverse proxy, multi-zone) needs the allowlist or every legitimate request fails, or worse, the mismatch is worked around insecurely elsewhere.
+- Flag every environment variable whose name suggests a secret (contains `KEY`, `SECRET`, `TOKEN`, `PASSWORD`, `CREDENTIAL`, or equivalent) and is prefixed `NEXT_PUBLIC_`. Any `NEXT_PUBLIC_` variable is inlined into the JavaScript bundle at build time and shipped to every client, full stop — there is no runtime gate that can retroactively hide it once bundled. The safe fix is to drop the prefix and read the value only from server-side code via `process.env.API_KEY` (or the equivalent unprefixed name), never from a Client Component.
+- Flag `images.dangerouslyAllowLocalIP: true` in `next.config.js` as a structural SSRF risk unless the codebase demonstrably validates every dynamic `src` value against a hardcoded external-hostname allowlist before it reaches the `<Image>` component.
+- Flag any `NextResponse.rewrite()` call (or `rewrites()` destination) whose target URL is built directly from user-controlled input (query parameters, headers, request body) with no hostname allowlist check on the resolved value before the rewrite call — this is SSRF/open-redirect via the rewrite backend, not a cosmetic routing bug.
+- Never execute, build, or run application code, and never send live requests, as part of this review; this is a static-review skill (Read/Grep/Glob only).
+- Load only the reference needed for the concern in scope.
+
+## 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 decision tree per defect class, and the required output shape.
+- [Middleware and Server Actions boundary defects](references/middleware-and-server-actions.md) — load only when reviewing `middleware.ts`/`.js`, its `matcher`, or Server Action CSRF configuration.
+- [Environment variables and SSRF/redirect surfaces](references/env-and-ssrf-surfaces.md) — load only when the review scope includes `.env*` files, `NEXT_PUBLIC_*` usage, `images.dangerouslyAllowLocalIP`, or a rewrite/redirect destination built from dynamic input. Includes the OWASP SSRF/open-redirect grounding reference; load that citation only when such a finding is actually present.
+
+## Response minimum
+
+Return, at minimum:
+
+- the middleware file(s), Server Action(s), `next.config.js`, and/or environment file(s) in scope,
+- ranked findings with file:line evidence, defect category (`middleware-auth-gap`, `csrf-origin`, `secret-leak`, or `ssrf-redirect`), the concrete data-flow trace (the `matcher` pattern and the excluded path's own auth handling, the `serverActions` config and its deployment topology, the environment variable declaration and its usage site, or the origin-to-sink path for the SSRF/redirect finding), and a fix sketch matching Next.js's documented pattern,
+- for every middleware-auth-gap finding, an explicit statement of whether the excluded path's own handler independently verifies the session — never approve on the assumption it does,
+- evidence level per finding (`repo evidence`, `documentation-based`, or `inference`), with structural risk findings explicitly labeled as structural risk, not as confirmed-exploited,
+- verdict (approve / approve-with-notes / block),
+- open questions or scope the review could not cover (e.g., "confirming actual cross-origin CSRF success requires a live cross-origin request, not static review").

package/skills/frontend/nextjs-server-security-review/metadata.json

@@ -0,0 +1,29 @@
+{
+  "id": "nextjs-server-security-review",
+  "name": "Next.js Server Security Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews Next.js middleware, Server Actions, next.config.js, and environment-variable files for middleware matcher exclusions that silently skip auth on Server Functions, Server Actions missing allowedOrigins CSRF protection, secrets leaked via NEXT_PUBLIC_ prefixes, and SSRF/open-redirect via dangerouslyAllowLocalIP or unvalidated rewrite destinations, grounding claims via Context7 and Next.js's own documentation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://nextjs.org/docs/app/building-your-application/authentication",
+    "https://nextjs.org/docs/app/guides/data-security",
+    "https://nextjs.org/docs/app/guides/environment-variables",
+    "https://nextjs.org/docs/app/api-reference/file-conventions/proxy",
+    "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 middleware matcher exclusion is a zero-trust boundary defect (authorization silently skipped on excluded paths), a missing serverActions.allowedOrigins is a CSRF gap, a NEXT_PUBLIC_-prefixed secret is a build-time data exposure with no runtime remediation once shipped, and dangerouslyAllowLocalIP or an unvalidated rewrite destination is a server-side request forgery / open-redirect vector. Every finding in this skill defaults to HIGH severity unless proven otherwise with concrete repo evidence. Static-review-only skill: it reads and greps middleware, Server Action, config, and environment files but never executes, builds, or runs application code, and never sends live requests.",
+  "last_verified": "2026-07-03",
+  "path": "skills/frontend/nextjs-server-security-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/nextjs-server-security-review/references/env-and-ssrf-surfaces.md

@@ -0,0 +1,73 @@
+# Environment Variables, Image SSRF, and Rewrite/Redirect Injection
+
+Use this reference only when the review scope includes `.env*` files, `NEXT_PUBLIC_*` usage, `images.dangerouslyAllowLocalIP` in `next.config.js`, or a rewrite/redirect destination built from dynamic input. The OWASP SSRF/open-redirect citation is loaded only when such a finding is actually present — do not cite it preemptively in a review with no SSRF/redirect surface.
+
+## What people get wrong: `NEXT_PUBLIC_` secrets
+
+The naive assumption is:
+
+> "I'll just prefix it with `NEXT_PUBLIC_` so the client component I'm writing right now can read it — I'll clean it up later."
+
+Wrong, and unrecoverable after the fact. Next.js's own documentation is direct: environment variables prefixed `NEXT_PUBLIC_` are inlined into the JavaScript bundle at build time (`documentation-based`, Next.js environment-variables guide). This is not a runtime gate that can be toggled off later — every client that has ever loaded a build containing the value has received it, in plaintext, in a bundle they can inspect via browser devtools or by fetching the JS file directly. Rotating the underlying secret afterward does not undo the exposure of the old value's existence, format, or any access it already granted before rotation.
+
+## Officially grounded rule
+
+Non-`NEXT_PUBLIC_` environment variables are exclusively available in the Node.js server environment and are never sent to the browser (`documentation-based`, Next.js environment-variables guide). The correct pattern is:
+
+```txt
+# .env
+API_KEY=<REDACTED_secret_value>
+```
+
+```js
+// Server Action or Route Handler only — never a Client Component
+export async function myServerAction() {
+  const key = process.env.API_KEY
+  // ...
+}
+```
+
+## Non-negotiable design rules
+
+### 1. Flag by name pattern, then confirm by value shape
+
+Any `NEXT_PUBLIC_`-prefixed variable whose name contains `KEY`, `SECRET`, `TOKEN`, `PASSWORD`, `CREDENTIAL`, or an obvious equivalent is a finding regardless of the value shown in the file — even a placeholder or rotated value in a committed `.env.example` demonstrates the naming pattern will leak the real value wherever it is actually set.
+
+### 2. A genuinely public value under `NEXT_PUBLIC_` is not a finding
+
+An analytics ID, a public feature-flag name, or a publishable (not secret) API key that the vendor itself documents as safe for client exposure (e.g., a Stripe *publishable* key, as opposed to a *secret* key) is the correct, intended use of the prefix. Do not manufacture a finding for a variable that is genuinely meant to be public — check the vendor's own documentation for whether a given key type is designed for client exposure before flagging it.
+
+## What people get wrong: image optimization SSRF
+
+The naive assumption is:
+
+> "`dangerouslyAllowLocalIP` just lets me test with a local dev image server, it's not a real security control."
+
+The name is the warning. Enabling `dangerouslyAllowLocalIP` allows the built-in image optimizer to fetch a `src` URL that resolves to a loopback or internal-network address. Combined with any dynamic (user- or attacker-influenced) `src` value, this becomes a classic SSRF primitive: an attacker supplies a URL pointing at an internal service (a cloud metadata endpoint, an internal admin panel, a database's HTTP interface) and the server-side image optimizer fetches it on the attacker's behalf (`documentation-based`, Next.js image-configuration guide — generally not recommended due to potential SSRF risk).
+
+## Non-negotiable design rule
+
+`images.dangerouslyAllowLocalIP: true` is a finding unless every dynamic `src` value reaching `<Image>` is validated against a hardcoded allowlist of safe external hostnames before it is used. `remotePatterns`/`domains` configuration that is itself permissive (a wildcard hostname pattern) does not clear this finding — the two controls are independent; a broad `remotePatterns` plus `dangerouslyAllowLocalIP: true` is worse, not better.
+
+## What people get wrong: rewrite/redirect destination injection
+
+The naive assumption is:
+
+> "`NextResponse.rewrite()`/a dynamic rewrite is just routing logic, not a security-sensitive sink."
+
+Wrong when the destination is built from user-controlled input. `NextResponse.rewrite(new URL(userControlledValue, request.url))` (or an equivalent `rewrites()` destination built from request data) lets an attacker supply a URL that the rewrite forwards the request to — either an internal service (SSRF) or an external attacker-controlled host (functionally an open redirect, since the response the client ultimately sees originates from the rewritten destination).
+
+## Non-negotiable design rule
+
+Any rewrite/redirect destination whose value traces back to user-controlled input (a query parameter, a header, a request body field) must pass through a hardcoded hostname allowlist check *before* the rewrite/redirect call — not merely be parsed with `new URL()` (which validates syntax, not safety) and passed straight through. Resolve the value to a local variable, check it against the allowlist, and only then call `NextResponse.rewrite()`/return the redirect. A destination built entirely from fixed, developer-authored literals is not a finding.
+
+## OWASP grounding (load only when an SSRF/redirect finding is present)
+
+Server-Side Request Forgery is the vulnerability class both `dangerouslyAllowLocalIP` misuse and unvalidated rewrite destinations produce: server-side code is induced to make a request to a location the attacker chose rather than the application developer, potentially reaching internal-network resources otherwise unreachable from the public internet. The OWASP SSRF reference (listed in this skill's `official_docs`) provides the vendor-neutral grounding for why this defect class is treated as HIGH severity by default — it commonly enables internal network reconnaissance, cloud metadata credential theft, or bypass of network-perimeter controls, not merely a routing inconvenience. Cite it only in the specific finding write-up for a confirmed or suspected SSRF/redirect defect, not as boilerplate in every review.
+
+## Verification targets
+
+- Grep every `.env*` file and any code referencing `process.env.NEXT_PUBLIC_` for a secret-shaped variable name.
+- Grep `next.config.js` for `dangerouslyAllowLocalIP` and check its value; if `true`, grep the codebase for every dynamic `<Image src=` binding and trace its origin.
+- Grep for `NextResponse.rewrite(` and `rewrites()` array entries; for each, trace the `destination`/URL argument's origin backward through variables to its source (literal, env var, or user-controlled request data).
+- Grep for a hostname allowlist check (`.includes(`, `ALLOWED_HOSTS`, or an equivalent project-specific allowlist array) and confirm its call site sits between the user-controlled origin and the rewrite/redirect call, not merely present elsewhere in the file.

package/skills/frontend/nextjs-server-security-review/references/middleware-and-server-actions.md

@@ -0,0 +1,67 @@
+# Middleware Matcher Exclusions and Server Actions CSRF
+
+Use this reference only when reviewing `middleware.ts`/`.js`, its `matcher` configuration, or a Server Action's CSRF posture in `next.config.js`.
+
+## What people get wrong: matcher exclusions
+
+The naive assumption is:
+
+> "Middleware runs before every request, so anything I check in middleware protects the whole app."
+
+Wrong, for any path the `matcher` excludes. A `matcher` written as a negative lookahead — e.g. `'/((?!api|_next).*)'` — is not just "skip static assets," it is "skip every path matching that lookahead, including API routes hosting Server Actions and Route Handlers." Next.js's own documentation on proxy execution order is explicit and non-negotiable on this point: a Proxy matcher that excludes a path also skips Server Function calls on that path (`documentation-based`, Next.js proxy/middleware docs). If the only auth check in the codebase lives inside middleware, and the matcher excludes `/api`, then every Server Action and Route Handler under `/api` runs with **zero** authorization enforcement from middleware — because middleware never runs for them at all.
+
+## Non-negotiable design rules
+
+### 1. A matcher exclusion is not evidence of anything — it is the absence of evidence
+
+Do not treat "middleware exists in this project" as sufficient. For each path the `matcher` excludes, that path's *own* handler must independently verify the session. There is no such thing as partial credit for "the matcher probably wasn't meant to exclude sensitive routes" — read the actual regex and the actual excluded paths.
+
+### 2. Distinguish an explicit allowlist matcher from an exclusion-style matcher
+
+A `matcher` that explicitly lists the paths middleware should run on (e.g. `['/dashboard/:path*', '/admin/:path*']`) is a fundamentally different risk shape than a negative-lookahead exclusion matcher (e.g. `['/((?!api|_next).*)']`). The explicit-allowlist form makes it obvious which paths get middleware coverage and, by construction, does not accidentally exclude an API route someone forgot about. Recommend this form when a matcher-exclusion gap is found.
+
+### 3. Trace what each Server Action actually checks
+
+For any Server Action (`'use server'` function) reachable from an excluded path, read its full body. A session check must be visible inside that function — not merely assumed because "there's an auth library imported at the top of the file." An import with no corresponding call site inside the action is not a check.
+
+## What people get wrong: Server Actions CSRF
+
+The naive assumption is:
+
+> "Next.js handles CSRF for Server Actions automatically, so I don't need to configure anything."
+
+Half right. Next.js's built-in protection only allows `POST` requests and compares the request's `Origin` header to its `Host` header, aborting on mismatch (`documentation-based`, Next.js data-security guide). That default works for a simple same-origin deployment. It silently breaks down — or gets worked around insecurely — for any deployment where `Origin` and `Host` legitimately differ for real production traffic: an app behind a reverse proxy, a multi-zone setup where one domain fronts several Next.js apps, or a staging environment fronted by a different domain than the app's own `Host`.
+
+## Officially grounded rule
+
+`serverActions.allowedOrigins` in `next.config.js` lets the framework compare the Server Action request's origin against an explicit, safe allowlist instead of only the automatic `Host`-header comparison:
+
+```js
+/** @type {import('next').NextConfig} */
+module.exports = {
+  experimental: {
+    serverActions: {
+      allowedOrigins: ['my-proxy.com', '*.my-proxy.com'],
+    },
+  },
+}
+```
+
+(`documentation-based`, Next.js data-security and multi-zone guides.)
+
+## Non-negotiable design rules
+
+### 1. A `serverActions` block missing `allowedOrigins` is not automatically safe
+
+If the deployment is same-origin only (no reverse proxy, no multi-zone, `Origin` and `Host` always match for real traffic), omitting `allowedOrigins` is the documented safe default — do not manufacture a finding where none exists. But if the deployment topology is cross-origin (reverse proxy, multi-zone, CDN rewriting `Host`), a `serverActions` block that configures other options (`bodySizeLimit`, etc.) but omits `allowedOrigins` is the exact CSRF gap this rule exists to catch. Confirm the deployment topology before judging severity — check `next.config.js` `rewrites()`, deployment docs, or infrastructure config for reverse-proxy/multi-zone evidence.
+
+### 2. `allowedOrigins` entries must be the actual safe origins, not a wildcard-everything pattern
+
+`allowedOrigins: ['*']` (or an equivalent catch-all) defeats the purpose of an allowlist — it accepts CSRF requests from any origin. Flag a wildcard-everything entry the same as a missing `allowedOrigins` key.
+
+## Verification targets
+
+- Grep `middleware.ts`/`.js` for `matcher:` and inspect the pattern for a negative lookahead (`(?!...)`) versus an explicit path list.
+- Grep every file the matcher excludes for `'use server'` and read each exported action's full body for a session/auth check.
+- Grep `next.config.js` for `serverActions:` and check whether `allowedOrigins` is a sibling key inside that same object.
+- Grep deployment config / `rewrites()` / infra docs for reverse-proxy or multi-zone evidence to determine whether a missing `allowedOrigins` is actually a gap or a legitimate same-origin default.

package/skills/frontend/nextjs-server-security-review/references/workflow-and-output.md

@@ -0,0 +1,51 @@
+# Review Workflow and Findings Contract
+
+Use this reference for the step-by-step review procedure and the required output shape. Load the other two references only for the specific defect class the middleware, Server Action, config, or environment file under review actually raises.
+
+## Prerequisites
+
+- Read `package.json` to confirm the Next.js major version and whether the app uses the App Router or Pages Router. `experimental.serverActions` configuration keys, middleware conventions, and rewrite/redirect APIs differ across major versions and routing modes; do not apply App Router API names to a Pages Router codebase or vice versa.
+- Locate every candidate file in scope: `middleware.ts`/`middleware.js` at the project root, `next.config.js`/`next.config.mjs`, any `.env*` file, and any file containing a `'use server'` directive or exported Server Action.
+
+## Workflow
+
+1. **Locate `middleware.ts`/`.js` and read its exported `config.matcher`.** Determine whether the `matcher` pattern excludes any path via a negative lookahead (e.g. `(?!api|_next)`). See `references/middleware-and-server-actions.md` for the decision tree.
+2. **For every path the matcher excludes, locate that path's own handlers** (Route Handlers, Server Actions) and confirm each one independently verifies the session/auth state inside its own function body — never assume middleware covers it.
+3. **Locate `next.config.js` and read any `experimental.serverActions` block.** If the deployment topology involves a reverse proxy or multi-zone setup (check deployment docs, `rewrites()`/proxy config, or ask if unclear), confirm `allowedOrigins` is present in that block and lists the actual production origins.
+4. **Grep every `.env*` file and every `process.env.NEXT_PUBLIC_*` usage** for a variable name suggesting a secret (`KEY`, `SECRET`, `TOKEN`, `PASSWORD`, `CREDENTIAL`, or equivalent). See `references/env-and-ssrf-surfaces.md`.
+5. **Grep `next.config.js` for `images.dangerouslyAllowLocalIP`.** If `true`, confirm dynamic `src` values passed to `<Image>` are validated against a hardcoded external-hostname allowlist somewhere on their data-flow path.
+6. **Grep for `NextResponse.rewrite(` and `rewrites()` destinations.** For each, trace the destination value's origin backward. If it is built from user-controlled input (query parameters, headers, request body) with no hostname allowlist check before the rewrite call, this is an SSRF/open-redirect finding.
+7. **Produce ranked findings** using the output contract below.
+
+## Decision tree
+
+- Middleware `matcher` excludes a path via negative lookahead, and that path's own handler has no independent session check → **HIGH** finding, `middleware-auth-gap`. Cite the documented execution-order rule directly (`documentation-based`): a Proxy matcher that excludes a path also skips Server Function calls on that path.
+- Middleware `matcher` excludes a path, but that path's own handler (Server Action or Route Handler) demonstrably verifies the session itself → not a finding for that path; note it explicitly as reviewed-and-clear.
+- `serverActions` block exists, deployment is cross-origin (reverse proxy/multi-zone), and `allowedOrigins` is absent from that block → **HIGH** finding, `csrf-origin`.
+- `serverActions` block exists and includes `allowedOrigins` listing the actual production origins, or the deployment is same-origin only and the key is legitimately omitted → not a finding.
+- A `NEXT_PUBLIC_`-prefixed variable name matches a secret-shaped pattern (`KEY`/`SECRET`/`TOKEN`/`PASSWORD`/`CREDENTIAL`) → **HIGH** finding, `secret-leak`, regardless of whether the value has been rotated since — the bundle already shipped it to every prior client that loaded the page.
+- A `NEXT_PUBLIC_`-prefixed variable holds genuinely non-secret data (an analytics ID, a public feature flag) → not a finding.
+- `images.dangerouslyAllowLocalIP: true` with no demonstrable `src` allowlist validation → **HIGH** finding, `ssrf-redirect`.
+- `images.dangerouslyAllowLocalIP` is `false` or absent (the default) → not a finding.
+- `NextResponse.rewrite()`/rewrite destination built from user-controlled input with no hostname allowlist check before the call → **HIGH** finding, `ssrf-redirect`.
+- Rewrite destination is a fixed literal path, or a dynamic value is checked against a hardcoded allowlist before the rewrite call → not a finding.
+
+## Output contract
+
+Every response from this skill must return:
+
+1. **Scope** — the middleware file(s), Server Action(s), `next.config.js`, and/or environment file(s) reviewed.
+2. **Ranked findings** — each with file:line, defect category (`middleware-auth-gap` / `csrf-origin` / `secret-leak` / `ssrf-redirect`), the concrete data-flow trace (matcher pattern and excluded-path handler status, serverActions config and deployment topology, environment variable declaration and usage site, or origin-to-sink path for SSRF/redirect), and a fix sketch matching Next.js's documented pattern.
+3. **Middleware-auth-gap status per excluded path** — an explicit statement of whether the excluded path's own handler independently verifies the session; never infer one does.
+4. **Evidence level per finding** — `repo evidence`, `documentation-based`, or `inference`. Label structural risk findings as structural risk explicitly — do not imply confirmed exploitation without live evidence (e.g., a captured cross-origin CSRF success, a confirmed SSRF callback).
+5. **Verdict** — approve / approve-with-notes / block.
+6. **Open questions or out-of-scope items** — e.g., "confirming actual cross-origin CSRF exploitation requires a live cross-origin request, not static review," or "component-level data-fetching patterns in this same file are out of scope — recommend a general Next.js review if needed."
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve a middleware `matcher` that excludes `/api` (or another path) as sufficient authorization coverage without checking whether that excluded path's own handlers verify the session — "middleware is there" is not evidence for a path middleware never runs on,
+- skip the `serverActions.allowedOrigins` check because "we haven't seen a CSRF incident" — this defect class is structural and often invisible until an attacker actually attempts a cross-origin form submission,
+- clear a `NEXT_PUBLIC_`-prefixed secret because "we're going to rotate it" — rotation does not undo exposure already shipped to every client that loaded a build containing the old value, and the review is about the structural leak, not the current key's live validity,
+- downgrade an untraced SSRF/rewrite finding to informational because "it's probably fine" — this skill's default is HIGH for exactly this class of unproven claim.

package/skills/frontend/nuxt-fullstack-security-review/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: nuxt-fullstack-security-review
+description: Statically review 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, nuxt-security), grounded in Nuxt's own documentation via Context7.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-03"
+  category: security
+---
+
+# Nuxt Fullstack Security Review
+
+## Purpose
+
+Review Nuxt 3/4 full-stack code — `nuxt.config.ts`, `composables/`, `plugins/`,
+`server/api/`, `server/routes/`, `server/middleware/`, and templates using
+`useState`/`v-html` — for five defect classes Nuxt's own documentation and its
+long-lived Nitro server model make security-critical: (a) private secrets placed
+under `runtimeConfig.public` (or fed by `NUXT_PUBLIC_*` env vars) so they ship in the
+client bundle, (b) `useState`/module-scope reactive or mutable state leaking across
+requests in Nitro's single long-lived process, (c) server-route SSRF via
+`$fetch`/`ofetch` to a user-controlled URL and blind forwarding of
+`useRequestHeaders()`/credentials, (d) `NuxtPayload`/`useState` data reaching an
+unsanitized render sink (XSS), and (e) missing security response headers
+(`routeRules` `headers`, the `nuxt-security` module, `useResponseHeader`). This
+skill exists so the review stays anchored to these five documented, structural
+defect classes instead of drifting into a general "Nuxt code review."
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a Nuxt `nuxt.config.ts` `runtimeConfig`/`routeRules` block for
+  secret-exposure or missing-header risk,
+- review a `server/api/*` or `server/routes/*` handler that calls out to another
+  service (`$fetch`/`ofetch`/`event.$fetch`),
+- investigate a report of one user seeing another user's data from a Nuxt app — the
+  classic cross-request state pollution symptom,
+- assess whether a `useState`/payload value rendered with `v-html` is safe,
+- perform a pre-launch security review of a Nuxt 3/4 full-stack application.
+
+Do not use this skill for:
+
+- a Nuxt app's client-only component architecture, composable-extraction quality, or
+  reactivity-boundary design with no security angle — use
+  `vue-composition-api-architecture-review` instead,
+- general Vue SSR concerns (non-Nuxt `entry-server.js`, raw `@vue/server-renderer`
+  usage) with no Nuxt-specific API involved — use `vue-ssr-security-review` instead,
+- Vuex/Pinia store internals or Vue Router navigation-guard security with no
+  Nuxt-specific `runtimeConfig`/`server/`/`useState` surface — use
+  `vue-state-store-security-review` or `vue-router-navigation-security-review`
+  instead,
+- a bug that requires live traffic reproduction (concurrent-request load testing, a
+  captured cross-user response, an actual SSRF probe against a running deployment) to
+  confirm exploitation — static analysis proves the structural risk, not that it has
+  already been exploited in production.
+
+## Context7 Documentation Protocol
+
+- Resolve and query `/websites/nuxt_4_x` (primary; Nuxt 4 prose docs) and
+  `/websites/nuxt_3_x` (Nuxt 3 prose docs) before citing any `runtimeConfig`,
+  `useState`, `$fetch`/`event.$fetch`/`useRequestFetch`/`useRequestHeaders`,
+  payload/`devalue`, `routeRules`, or `useResponseHeader` behavior as fact. Both are
+  Nuxt's own documentation site content mirrored into Context7 — treat matches from
+  either as `documentation-based`.
+- Confirm which Nuxt major the target repo uses (`package.json`'s `nuxt` dependency)
+  before assuming version-specific defaults; the APIs this skill covers are stable
+  across 3/4, but state which major was confirmed when citing a claim.
+- The third-party `nuxt-security` module's exact default header set and
+  configuration surface is **not** covered by Nuxt's own Context7-indexed docs —
+  never state a specific default for it as `documentation-based`. Confirm its
+  presence/config by reading the repo's `nuxt.config.ts` directly, and label any
+  claim about its behavior `inference` unless corroborated by the module's own
+  documentation (not currently in scope for this skill's Context7 grounding).
+- Do not invent API names. If Context7 does not confirm an API or default, say so
+  explicitly and label the claim `inference`.
+- 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
+
+- Every finding in this skill's five defect classes defaults to HIGH severity
+  (missing-security-headers may be MEDIUM-to-HIGH depending on the app's actual
+  surface — see `references/ssrf-payload-and-response-headers.md`, Part 3). Do not
+  downgrade a structural `runtimeConfig` exposure, cross-request state leak, SSRF
+  path, or payload-XSS trace to informational because it has not been observed
+  exploited yet.
+- Trace every finding to a concrete file:line and a concrete data-flow path. A
+  finding that says "this might leak the secret" or "this fetch call could be
+  SSRF" without showing the specific config key, the specific module-scope
+  declaration and its reachability, or the specific origin-to-sink trace is a
+  guess, not a finding.
+- Classify every `runtimeConfig` key by its actual nesting (top-level = private,
+  under `public` = client-exposed) — never by variable name alone. A key named
+  `apiSecret` sitting inside `public` is exposed; a key named `baseUrl` sitting
+  outside `public` is still private and not itself a finding.
+- Classify every module-scope declaration on two axes before flagging it:
+  mutability/reactivity (only `useState`/`ref`/`reactive`/mutable objects are at
+  risk; immutable constants are not), and reachability from server-rendered code
+  (a declaration no server-rendered path ever touches is not a finding in this
+  scope).
+- Do not clear a `$fetch`/`ofetch`/`event.$fetch` call in a server route as safe
+  from SSRF just because it "looks like an API call" — trace the destination URL
+  to its origin and confirm either a hardcoded host or an explicit allowlist check
+  before the request fires.
+- Do not clear a header-forwarding call (`event.$fetch`'s default forwarding,
+  `useRequestHeaders(...)`, or manual header spreading) as safe just because
+  Nuxt documents the mechanism — the mechanism existing is not the same as its
+  use being scoped to only the headers actually needed and only trusted
+  destinations.
+- Do not approve a `useState`/payload value reaching a `v-html` binding unless a
+  named sanitizer call is visibly present on that exact traced path — a sanitizer
+  existing elsewhere in the codebase does not clear this bar.
+- Do not report "no security headers" as cleared just because *a* mechanism
+  exists somewhere in the config — confirm the `routeRules` glob (or module
+  config) actually covers the routes in scope before crediting it.
+- Never execute, build, or run application code, and never send live requests, as
+  part of this review; this is a static-review skill (Read/Grep/Glob only).
+- Load only the reference needed for the concern in scope.
+
+## 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 full decision tree across all five
+  defect classes, and the required output shape.
+- [runtimeConfig exposure and cross-request state pollution](references/runtime-config-and-cross-request-state.md)
+  — load when reviewing `nuxt.config.ts`'s `runtimeConfig` block, `NUXT_PUBLIC_*`
+  env vars, or `useState`/module-scope reactive/mutable declarations reachable
+  from server-rendered code.
+- [Server-route SSRF, header forwarding, payload XSS, and missing response headers](references/ssrf-payload-and-response-headers.md)
+  — load when reviewing a `server/api`/`server/routes` handler's outbound
+  `$fetch`/`ofetch`/`event.$fetch`/`useRequestFetch` calls, a `useState`/payload
+  value that renders somewhere, or `routeRules`/security-module configuration.
+- [Acceptance rubric](references/acceptance-rubric.md) — the authoritative list of
+  defects this skill must catch and the false positives it must not raise; consult
+  when unsure whether a pattern is in scope.
+
+## Response minimum
+
+Return, at minimum:
+
+- the `runtimeConfig`/`routeRules` blocks, module-scope declarations, server
+  routes, and/or template bindings in scope,
+- ranked findings with file:line evidence, defect category
+  (`runtimeconfig-exposure` / `cross-request-state-pollution` / `ssrf` /
+  `credential-forwarding` / `payload-xss` / `missing-security-headers`), the
+  concrete data-flow trace, and a fix sketch matching Nuxt's documented pattern,
+- for every `useState`/payload → render-sink finding, an explicit statement of
+  whether a sanitizer call is present on the traced path — never approve on the
+  assumption one exists elsewhere,
+- evidence level per finding (`repo evidence`, `documentation-based`, or
+  `inference`), with structural risk findings explicitly labeled as structural
+  risk, not as confirmed-exploited,
+- verdict (approve / approve-with-notes / block),
+- open questions or scope the review could not cover (e.g., "confirming actual
+  cross-request leakage requires concurrent-request load testing, not static
+  review").