Does Next.js need a WAF?

The fact that the developers of Next.js at Vercel enable their Web Application Firewall by default free for all accounts, suggests that yes, Next.js needs a WAF!

Throwing a network-level WAF in front of your application is an easy way to defend against attacks. Next.js is no different from any other web application in that sense. Although there are some out of the box protections in React from things like Cross Site Scripting (XSS), Next.js itself has had past vulnerabilities and unsafe coding can introduce others. You still need to follow a security checklist for Next.js.

But there are tradeoffs from using a WAF. Analyzing every request adds latency and different areas of your application may be higher risk than others. Arcjet tackles this differently through our Shield WAF feature - we still analyze requests for common threats, but do so in the background. This minimizes latency and helps avoid false positives because multiple requests can be analyzed.

Arcjet is also more closely integrated with your code so you can dynamically adjust your application logic depending on the response. You might want to instantly block suspicious requests from anonymous users, but if you know the user is signed into an enterprise account and completed 2FA, you may just want to flag the request or trigger an alert.

Network level proxy firewalls are a legacy architecture that doesn’t work well with modern applications. Choosing whether to add a WAF is now a more interesting discussion because it can be more deeply integrated with your code.

How can a WAF protect Next.js?

A WAF can help defend against attacks by scanning all incoming requests, looking for known attack patterns, and proactively blocking suspicious requests.

Arcjet includes Shield WAF as one of the features you can enable in our SDK. Through processing millions of requests, we see two main types of attacks in our WAF logs:

Passive scanning attacks

A lot of malicious web traffic is from passive scanners. This is usually high volume, low sophistication. For example, we see a lot of scanning for Wordpress config files and Windows remote code execution even though the application is clearly a Next.js app hosted on Vercel. 

We also see requests trying to take advantage of configuration mistakes, such as .env or .git files accidentally deployed, or plain text configuration files left behind.

If you’re using Next.js deployed to a modern platform like Vercel, Render, Railway, or Fly.io, then these requests are a minor annoyance. They can be easily blocked to reduce your infrastructure costs, but likely don’t represent much of a threat.

More concerning are targeted, passive attacks, such as scanners enumerating your forms, login routes, and API endpoints for SQL injection or other input-based attacks. These rarely succeed on the first request because the attacker is really enumerating your application opportunistically to see if something strange happens. A WAF can detect those attempts and proactively block the client before the exploration discovers something.

For these types of attacks, a WAF in front of Next.js is a nice bonus. It provides another layer of protection and can even reduce infrastructure costs because requests are blocked before your main code executes.

Active direct attacks

Like all popular software, Next.js has had past security vulnerabilities. Any dependencies you use may have security issues and your own code and contain mistakes, such as incorrect input validation leading to Cross Site Scripting, SQL Injection, or Server Side Request Forgery type issues.

These can be detected by more sophisticated scanning - looking for specific vulnerabilities because you know that the site is using Next.js.

For example, CVE-2024-34351 affected Next.js <14.1.1 where a specific Host header could result in a Server Side Request Forgery attack with Server Actions. This only affected self-hosted installations of Next.js due to how Vercel works.

Another issue from 2024 was CVE-2024-51479 where a middleware authorization bypass in Next.js <14.2.15 affected Next.js hosted everywhere. Vercel deployed mitigations for all applications on their platform, but others were vulnerable to attack.

In this case, the answer is that using a WAF as a security layer in front of Next.js is needed to help detect emerging vulnerabilities. These attacks all have signatures which can be detected and blocked if the WAF is regularly updated. This is important because you might not be able to update to a new version immediately, so having the protections applied through a managed WAF ruleset will mitigate any active attacks. This is where a WAF can really make a difference.

PCI v4 makes WAFs mandatory

If you are running any service that needs to comply with the PCI payments processing standards then you too will soon need to enable a WAF in front of Next.js. 

On March 31, 2025, PCI DSS 4.0 will take effect. This includes changes that mean a WAF moves from recommended (in PCI DSS 3) to required. Section 6.4.2 says:

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

Using a WAF is given as a specific 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

Making a WAF for Next.js

The big downside of network-level WAFs is they are generic. They have no understanding of your application so can’t customize rules based on things like tech stack (no point applying PHP detections for a Next.js application), the routes (should this endpoint return JSON or is it an HTML response?), or the session context (is a user logged into a paying account vs an anonymous user on your website?).

This is why we’ve designed the Arcjet Shield WAF to run as part of our native SDK. When you add a Shield rule, we analyze the request in the background with rules customized based on an understanding of the tech stack being protected.

As requests are processed, suspicious activity is monitored until a certain threshold is reached. This helps avoid false positives where legitimate traffic accidentally triggers a rule. 

We see this regularly when applying the rules from the open source OWASP Core Ruleset, which is integrated into Arcjet Shield for Pro plan users. This is a great repository of mitigations against common attacks, but has to be broad to cover all types of web applications.

We regularly monitor the results of Shield analysis and apply customizations based on our understanding of the type of traffic we expect to see. We already know which SDK and framework you’re using, so we can be much more targeted with the rules that get applied.

And of course since Arcjet rules are all just code, and you can see the reasons behind our decisions, your application can adjust in real time. The flexibility is there to decide what’s best for your situation.

Arcjet Shield is free for all users and the managed OWASP Core Ruleset is applied to Pro & Enterprise accounts. Enable it with just a few lines of code:

const aj = arcjet({
  key: process.env.ARCJET_KEY!,
  rules: [
    // Shield protects your app from common attacks e.g. SQL injection
    // DRY_RUN mode logs only. Use "LIVE" to block
    shield({
      mode: "DRY_RUN",
    }),
  ],
});

So do you need a WAF for Next.js?

If you need to be PCI compliant, then from March 31, 2025 the answer is yes; you need a WAF for Next.js.

For everyone else, enabling a WAF will give you another layer of security. Defense in depth is important because no layer can ever be 100% secure, so you probably should put a WAF in front of Next.js.