Does Next.js need a WAF?

Does Next.js need a WAF?

Yes. Next.js is a public web application. It needs a web application firewall (WAF) for the same reasons any other public app does: opportunistic scanners, targeted exploits of known CVEs, and (if you process cards) PCI DSS 4.0, which is in effect.

Vercel enabling its WAF by default is a hint, not a proof. Next.js has had vulnerabilities. React reduces some XSS cases when you render text nodes. It does not stop SQL injection in a Route Handler, a middleware authorization bypass, or a scanner walking /api. You still follow a Next.js security checklist. A WAF is one layer on that list.

The interesting choice is where the WAF runs. A network proxy in front of the origin is easy to switch on and adds latency to every request. An SDK in the handler can apply the same attack detections with the session and the route in scope, and it can fail per action instead of per hostname.

How can a WAF protect Next.js?

A WAF inspects incoming HTTP requests for known attack patterns and denies the ones that match. In practice the traffic falls into two groups.

Passive scanning. Most of the junk is high volume and low skill: probes for WordPress install paths, Windows RCE paths, leftover .env and .git files, leftover config dumps. On Vercel, Render, Railway, or Fly.io those requests are a cost and noise problem more than a likely breach. Blocking them still saves origin time. The more useful scanner is the one that enumerates your login, signup, and form routes looking for injection. A WAF that sees that pattern can deny the client before the walk finds the sloppy handler.

Active, targeted attacks. Next.js and its dependencies have had exploitable bugs. CVE-2024-34351 was a Server Actions Host-header SSRF on self-hosted Next.js before 14.1.1. CVE-2024-51479 was a middleware authorization bypass fixed in 14.2.15. CVE-2025-29927 skipped middleware with x-middleware-subrequest and needed 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3. Those attacks have request signatures. A maintained WAF ruleset can deny them while you are still scheduling the upgrade. That is the case where a WAF earns its keep. For the middleware CVEs, see Next.js middleware bypasses.

A WAF does not patch your app. It buys time and catches the request shapes you already know are hostile.

How does a network WAF compare to a security SDK?

Use both when you can. Use the SDK when the decision needs the user, the route, or a dry-run you can ship in the same commit as the feature.

A network WAF has no idea you are on Next.js, so it will still apply PHP detections and still miss a handler that should return JSON. It cannot say "deny this Shield match for anonymous users, and only flag it for an enterprise session that already passed 2FA." An SDK can, because the session is already in the function.

The usual production shape is an edge WAF or CDN for floods and coarse filtering, plus an SDK on the routes that create accounts, take payments, or mutate data. How to detect and block attacks at runtime is the handler-level pattern. Rate limiting is the sibling control you almost always pair with the WAF rule.

Does PCI DSS 4.0 require a WAF?

If you must comply with PCI DSS, yes. Get the dates right, because two separate milestones are often merged into one. PCI DSS v3.2.1 was retired on 31 March 2024, which is when v4.x became the standard you are assessed against. v4.0.1, a limited revision with no new requirements, has been the only active version since 31 December 2024. Requirement 6.4.2 was one of the 51 future-dated requirements, so it was best practice until 31 March 2025 and has been mandatory since. An assessment in 2026 tests it in full, against v4.0.1.

What 6.4.2 changed is narrower than "a WAF is now required." Under v3.2.1, requirement 6.6 was already mandatory, but it let you choose between a WAF and manual or automated application vulnerability review. 6.4.2 removed the review option:

For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks.

The standard gives a WAF as the example:

A web application firewall (WAF), which can be either on-premise or cloud-based, installed in front of public-facing web applications to check all traffic, is an example of an automated technical solution that detects and prevents web-based attacks.

If your Next.js app is in PCI scope, you need that automated, continuous control, and a periodic pentest no longer substitutes for it. An edge WAF in front of the origin satisfies the example. An in-application WAF that inspects every public request is the same class of control with more application context. Your Qualified Security Assessor decides what counts. There is no future start date left to wait for.

How do you add a WAF to a Next.js app with Arcjet?

Arcjet Shield is the WAF rule in the Arcjet SDK. You install @arcjet/next, add shield to the client, and call aj.protect(req) at the top of the handler. Analysis uses rules that already know the SDK and framework, so you are not running a generic PHP ruleset against a Next.js app.

Suspicious requests accumulate until a threshold is crossed. That threshold is why Shield can run without adding a blocking hop to every request, and why a single noisy payload is less likely to lock out a real user. Shield includes rules from the OWASP Core Rule Set, covering SQL injection, cross-site scripting, local and remote file inclusion, PHP and Java code injection, Shellshock, shell injection, and session fixation. Those rules are broad on purpose, and Arcjet combines them with its own analysis of request patterns over time.

Because the decision is a value in your handler, you choose the response. Deny anonymous traffic that trips Shield. For a signed-in enterprise user, log and continue, or step up authentication. That branch is application code, not a ticket to a WAF admin.

Enable Shield in dry run first so you can see what it would deny on your traffic:

1
import arcjet, { shield } from "@arcjet/next";
2

3
const aj = arcjet({
4
  key: process.env.ARCJET_KEY!,
5
  rules: [shield({ mode: "DRY_RUN" })],
6
});
7

8
export async function POST(req: Request) {
9
  const decision = await aj.protect(req);
10
  if (decision.isDenied()) {
11
    return new Response("Forbidden", { status: 403 });
12
  }
13
  // Your handler
14
}

shield({ mode: "DRY_RUN" }) logs only. Switch that rule to mode: "LIVE" when you are ready to block. Add detectBot and a slidingWindow or fixedWindow on the same client when the route is public and cheap to flood.

Is an edge WAF enough by itself?

No. An edge WAF is the right tool for volumetric attack and for signatures that should never reach the origin. It is the wrong tool to be the only authorization or the only injection defense.

The March 2025 Next.js middleware bypass is the concrete example. Middleware looked like a perimeter. A single header skipped it. Teams that also authorized in the route, and that ran Shield in the handler, still had a deny path. Teams that only had middleware did not. Put the WAF where the request still goes after middleware is skipped: in the handler.

Defense in depth is the honest answer for everyone who is not in PCI scope. No layer is complete. Next.js needs a WAF, and the WAF needs a second place to run besides the edge.

So do you need a WAF for Next.js?

Yes. If you are in PCI scope, PCI DSS 4.0 already requires an automated technical solution that detects and prevents web attacks, and a WAF is the example the standard names. For everyone else, a WAF is the layer that denies scanners and known-vulnerability shapes while you patch. Prefer an SDK you can dry-run and branch on, behind whatever CDN you already use, rather than a generic proxy that cannot see the session. That is a WAF for Next.js that lives with the code it protects.