Input Sanitisation for Rich Text

If your application accepts HTML from users (rich text editors, markdown with HTML allowed), sanitise before rendering:

The sanitisation must happen before dangerouslySetInnerHTML. Sanitising only on the client is insufficient — SSR renders the HTML server-side first.

---

Dependency Auditing

External packages are part of your attack surface. A supply chain attack through a compromised npm package can exfiltrate environment variables, secrets, or user data.

The CI check:

For applications where dependencies are a primary concern (fintech, healthcare), tools like socket.dev or Snyk provide deeper analysis: detecting suspicious package behaviour, not just known CVEs.

---

Where We Go From Here

A-14 covers the deployment infrastructure choices that go beyond Vercel — self-hosted with Docker and Kubernetes, WebSockets and long-lived connections, and when serverless is the wrong choice. After hardening the application in A-13, A-14 addresses the infrastructure it runs on.

---

The CSP Nonce Cache Conflict

Nonce-based CSP works by generating a unique random value per request, embedding it in the <script nonce="..."> tag, and including it in the Content-Security-Policy header. A script only executes if its nonce attribute matches the one in the header. Since the nonce is different for every request, an XSS attacker can't predict it and can't inject scripts that will execute.

The implementation in Middleware is correct:

The problem: if that page is served from a CDN cache, the nonce is no longer unique per request. It's the nonce that was generated when the page was first cached — the same value for every user who receives the cached response.

A static nonce is not a nonce. It's a constant. An attacker who can read the CSP header of one cached response now knows the nonce value for every user receiving that response. The entire security guarantee collapses.

This failure mode doesn't appear in local development (no CDN caching) and doesn't appear on a fresh Vercel deployment of a fully dynamic app. It appears when:

• You have a CDN in front of your Next.js server
• The CDN caches pages (via Cache-Control: public or default caching rules)
• Those pages use nonce-based CSP

Fix 1: Force Cache-Bypass for Nonce-Protected Pages

The most direct fix: any page that uses a nonce must not be cached at the CDN layer.

Cache-Control: private, no-store instructs CDNs to never cache the response. Every request hits the origin, every response gets a fresh nonce. The downside: you lose CDN caching for all pages covered by this Middleware.

For applications where most pages are dynamic (authenticated dashboards, personalised feeds), this is acceptable. For content-heavy sites where static caching is critical, use Fix 2.

Fix 2: Hash-Based CSP for Cacheable Pages

For static or ISR pages that benefit from CDN caching, nonce-based CSP is architecturally wrong — you can't have both a unique-per-request nonce and a cached response. Use hash-based CSP instead.

Hash-based CSP lists the SHA-256 hash of each allowed inline script. Unlike nonces, hashes are deterministic — the same script always produces the same hash. CDN-cached responses with hash-based CSP remain valid.

The downside: you must know the exact content of every inline script at build time. Any dynamic inline script (one whose content varies at runtime) cannot use hash-based CSP — use nonces for those pages and forfeit CDN caching.

The Hybrid Model

Real applications use both:

• Dynamic pages (authenticated, personalised): nonce-based CSP + Cache-Control: private, no-store
• Static/ISR pages (marketing, content): hash-based CSP + Cache-Control: public, max-age=3600

Apply CSP in Middleware and branch on whether the request is for a dynamic or static route:

---

SSRF via next/image — The Open Proxy Misconfiguration

next/image optimises remote images by proxying them through /_next/image?url=.... The url parameter is the address of the image to fetch. Next.js fetches that URL server-side, optimises it, and returns it to the client.

This is a Server-Side Request Forgery (SSRF) vector. If the remotePatterns configuration is too permissive, an attacker can use your image optimisation endpoint to make arbitrary HTTP requests from your server.

The dangerous pattern:

With this configuration:

The AWS instance metadata endpoint (169.254.169.254), internal Kubernetes services (kubernetes.default.svc), internal Redis instances, and other services accessible from your server's network are all reachable through an unrestricted next/image SSRF.

The ** wildcard is not safe. It's frequently copied from documentation examples meant for development use. In production, it's an open SSRF proxy.

Fix: Restrict remotePatterns to Exact Domains

Subdomain wildcards (**.hostname.com) are acceptable — they restrict to a specific domain family. Top-level wildcards (**) are not.

Additional SSRF Mitigations

Block private IP ranges at the network layer. Configure your firewall or security group to block outbound connections from your Next.js server to RFC1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and the link-local range (169.254.0.0/16). This way, even if remotePatterns is misconfigured, the network blocks the request.

Disable next/image remote optimisation if you don't need it. If all your images are self-hosted or served from a fixed CDN, set unoptimized: true or don't configure remotePatterns at all — the endpoint returns 400 for unlisted domains by default.

Rotate credentials if you suspect exploitation. If you shipped a ** wildcard to production on AWS or GCP, assume the instance metadata endpoint was hit. Rotate your IAM credentials and audit your CloudTrail logs for unusual API calls from the instance.

---

SSRF via Server Actions — The Vector Nobody Threat-Models

The next/image SSRF above gets attention because it's a well-known misconfiguration with a documented fix. The Server Action version of the same bug gets almost none, because it doesn't look like a security-sensitive code path — it looks like a normal feature.

Any Server Action that takes a URL as input and fetches it server-side is an SSRF vector. "Preview this link," "verify this webhook responds," "fetch this RSS feed," "check if this image URL is valid" — all of these are, mechanically, the same thing as the next/image proxy: your server, not the user's browser, is making an outbound HTTP request to an address the user controls.

The vulnerable pattern:

This looks completely reasonable in a PR. It's a link preview feature — every product has one. The problem is that fetch(url) runs on your server, with your server's network access, and the user supplies url:

None of these addresses are reachable from the public internet. That's the point of putting them there. But your Next.js server can reach them, because it's running inside the same network — and the Server Action just became the attacker's tunnel in.

The fix: allowlist, or at minimum block the dangerous ranges.

The strongest fix is a domain allowlist, the same principle as remotePatterns for next/image:

When the feature genuinely needs to accept arbitrary domains (a general-purpose "preview any link" tool can't allowlist domains it's never seen), fall back to blocking the dangerous ranges instead — private/link-local IPs and the cloud metadata address specifically:

The allowlist approach is strictly safer when it's an option — an IP-range blocklist has to anticipate every way a hostname can resolve to something internal (including DNS rebinding, where a hostname resolves to a public IP at validation time and a private one at fetch time), and it's easy to miss one. Reach for the blocklist only when the feature's whole purpose is fetching arbitrary user-supplied domains.

---

Rate Limiting — Edge vs. Application Layer

A Server Action or Route Handler with no rate limiting is an open invitation: credential-stuffing against a login action, an expensive database-backed search hit thousands of times a second, a webhook endpoint hammered until it falls over. The question isn't whether to rate limit — it's where.

Edge / Middleware rate limiting runs in Middleware, ahead of your route or Server Action:

The upside: it rejects abusive requests before they touch your route handler, your database connection pool, or your Server Action logic — the cheapest possible place to say no. The cost has already been paid by the time application-layer rate limiting would reject the same request.

The constraints: Middleware runs on the Edge runtime, which means no arbitrary Node.js APIs (see the CSP nonce fix above — this is the same runtime, the same limitation). You can't use an in-memory Map to track request counts either, because Edge Middleware isn't guaranteed to run on the same instance between requests — you need an edge-compatible store like Upstash Redis or Vercel KV that's reachable over HTTP/fetch from any edge location.

Application-layer rate limiting runs inside the Server Action or Route Handler itself:

The upside: full Node.js APIs, full access to your session/auth context, and the ability to key the limit on things Middleware doesn't easily see — the authenticated user ID, their subscription tier, the specific action they're calling rather than just the route. The cost: by the time you reject the request, it's already been through routing, authentication, and whatever middleware ran before it — more resources spent per rejected request than an edge-layer block. It also only protects the routes that actually call your rate-limiting code; a Route Handler you forgot to wrap gets no protection at all, whereas Middleware's matcher covers everything that matches the pattern regardless of what the handler does internally.

A realistic recommendation: layer both, and give each layer a job it's good at.

• Edge Middleware: coarse, cheap, IP-based limits applied broadly — e.g. no more than N requests per IP per 10 seconds across all API routes. This is your defence against blunt-force abuse (scripted scraping, credential-stuffing bursts, a misbehaving client retrying in a loop) and it stops the request before it costs you anything.
• Application layer: fine-grained, per-user or per-action limits that need session context Middleware doesn't have — e.g. "this specific user can request at most 3 expensive reports per minute" or "this Server Action can be called at most once per second per authenticated session." This is your defence against a legitimate, authenticated user's client (or account) doing something excessive that a per-IP rule wouldn't catch, especially behind a shared corporate NAT where many legitimate users share one IP.

Neither layer alone covers both failure modes. Edge-only misses the "one authenticated user abusing one specific expensive action" case; application-only lets unauthenticated blunt-force traffic all the way through your stack before rejecting it.

---