# 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.

# 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.

# 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.