Next.js security: vulnerabilities to know before production

Next.js security: the issue is not limited to “updating the framework.” Before going live, you need to check the exact version, middleware usage, the chosen hosting, HTTP headers, and React dependencies. Since 2024, several Next.js vulnerabilities have affected authentication, cache, Server Components, and self-hosting. For a business leader, the challenge is simple: avoid having a technical choice speed up the project today but sharply increase the risk tomorrow.

Next.js security: what really changes for a web project

Next.js is a JavaScript framework based on React, used to create fast websites, SaaS platforms, customer portals, or editororial sites with server-side rendering. Server-side rendering means that part of the page is prepared by the server before it reaches the browser. This is excellent for performance and SEO, but it also creates additional entry points.

The risk is not theorical. In March 2025, the vulnerability CVE-2025-29927 was published with a CVSS score of 9.1, making it critical. It allowed certain authorization checks to be bypassed via an internal header, x-middleware-subrequest, in versions of Next.js earlier than 12.3.5, 13.5.9, 14.2.25, and 15.2.3.

For an SMB, the possible consequence is very concrete: an area normally protected, for example a back office, an extranet, or an order validation page, can become accessible if the architecture relies poorly on middleware. Middleware is a processing layer executed before the page, often used to filter access.

This point deserves a decision as early as the planning stage. Next.js can be a very good choice for an ambitious project, but only if the team plans for a maintenance budget. With that budget, it is sometimes better to choose a simpler, well-maintained foundation than a modern architecture left without follow-up after delivery.

Recent vulnerabilities to know before deployment

The vulnerabilities published by Vercel, GitHub, the NVD, or the React team show a clear pattern: the sensitive areas are authentication, cache, Server Components, URL rewrites, and certain self-hosted configurations. Server Components are React components executed on the server side to reduce the JavaScript sent to the browser.

Here are useful reference points for discussing with a service provider, without getting into code details:

Cache poisoning consists of getting the cache to store a bad response, then serving it to other visitors. It is discreet, sometimes difficult to diagnose, and particularly problematic on a high-traffic site. SSRF vulnerabilities, meanwhile, allow an attacker to force the server to call unintended internal or external resources.

On the projects we handle, we often see confusion between “the site works” and “the site is ready for production.” These are two different states. Production requires an additional level of control: logging, updates, backups, security testing, and a rollback plan.

Vercel, OVH, dedicated server: hosting changes the level of risk

Next.js is historically very closely associated with Vercel, the platform created by the framework’s publisher. This is not insignificant. Several security advisories specify that certain Vercel deployments are not affected by vulnerabilities impacting self-hosting, particularly cases related to rewrites, cache, or WebSocket upgrades.

Self-hosting means hosting on your own infrastructure or with a provider such as OVHcloud, Scaleway, AWS, Google Cloud, or a server managed by an IT service provider. It may be relevant for reasons of cost, sovereignty, compliance, or business integration. But it transfers more technical responsibility to the team operating the site.

The trap that non-technical people ignore: “Next.js runs on Node.js” does not mean that all features behave the same way everywhere. CDNs (content delivery networks), proxies, rewrites, server functions, and adapters can change actual behavior. Next.js 16.2, announced in 2026 with work on platforms and adapters, is moving precisely in this direction: the deployment context matters.

If you compare the options, also include the choice of JavaScript runtime, that is, the environment that runs the server code. To understand the differences between Node.js, Bun and Deno, this guide on choosing a JavaScript runtime in 2026 usefully complements the discussion.

Security checklist before going live

A Next.js security review does not need to be endless to be useful. Above all, it should be systematic. The goal is to detect costly mistakes before the site is publicly exposed.

• Check the exact version of Next.js, React, and React DOM, then compare them with the published GitHub/Vercel advisories.
• Ensure that the middleware does not porte access autorization to sensitive areas on its own.
• Filter dangerous incoming headers at the CDN or reverse proxy level, especially internal headers.
• Set up a CSP, Content Security Policy, that limits autorized scripts to reduce XSS risks.
• Test the cache: private pages never cached, public pages correctly invalidated.
• Plan for an update process with a staging environment and backup.
• Monitor logs and error alerts after each deployment.

The CSP deserves special attention. The official Next.js documentation indicates that it helps reduce the risks of XSS, clickjacking, and code injection. It also recommends Next.js v13.4.20 or later for proper nonce handling, those temporary tokens that autorize certain scripts in a controlled way.

Still, be careful: a poorly designed CSP gives a false impression of security. If it autorizes too many domains, or if untrusted data is injected into scripts beforeInteractive, it loses much of its value. In May 2026, Vercel/GitHub advisories specifically listed XSS issues related to the App Router, CSP nonces, and early scripts.

Budget and timelines: what to realistically plan for

In the French market, a light security review before a Next.js site goes live often costs around €1,500 to €4,000 before tax depending on scope. It generally covers versions, configuration, HTTP headers, sensitive routes, dependencies, and correction recommendations. For a business application with authentication, payments, or personal data, a more in-depth audit can exceed €6,000 to €12,000 before tax.

Timelines are reasonable if the issue is anticipated. Allow two to five business days for a targeted review, then a few additional days to corrige properly. If the audit comes the day before launch, the cost rarely increases on the initial invoice, but it explodes in the trade-offs: campaign postponement, team stress, quick corrections, and technical debt.

Honestly, this technology is only justified if you accept its maintenance pace. Next.js evolves quickly. That is a force for performance, SEO, and theuser experience, but it requires regular monitoring, especially with the App Router, Server Actions, and Server Components.

A simple showcase website can sometimes be better served by a well-secured WordPress, a static generator, or a more traditional architecture. On the other hand, for a client portal, a SaaS product, or an editorrial site connected to a Headless CMS, Next.js remains highly relevant if security is planned into the run budget.

Frequent mistakes that become expensive after launch

The first mistake is putting authentication at the “bord” of the site, then assuming everything is protected. The middleware can filter, but access checks must also exist on the server side, as close to the data as possible. Otherwise, a bypass vulnerability becomes much more serious.

Another mistake: confusing a minor update with a minor risk. Security patches sometimes arrive in versions that seem ordinary. Postponing a version upgrade for six months can leave the site exposed to documented attacks, and therefore easier to reproduce.

The choice of providers also matters. A team capable of delivering a polished interface is not always used to operations, monitoring, and emergency patches. If you are hesitating between internal resources, freelance, and an agency, this point on the ororganization of development for a small business helps establish the right criteria.

Finally, security must be tied to the project cycle. Classic scoping, testing, or poorly defined responsibility errors also weaken the technical side. The risks listed in mistakes to avoid lors when creating a website are often found in Next.js projects, with a greater impact lorsque the application handles customer data.

On the agency side, the instinct is to treat security as a production workstream, not as an end-of-project option. Defining this type of deployment upstream avoids most unpleasant surprises: target version, hosting, maintenance responsibilities, correction budget, and an emergency plan in case of a critical advisory.

FAQ on Next.js security

Is Next.js secure for a professional website?

Yes, Next.js can be secure for a professional website, provided it is maintained and configured correctly. The risk mainly comes from unpatched versions, poorly managed self-hosting, and access controls that are too centralized in the middleware.

Which version of Next.js should be used in production?

A supported and corrrected version must be used according to the latest Vercel/GitHub notices. In practice, always check the exact project branch, because the correctives published in 2025 and 2026 vary depending on Next.js 13, 14, 15, or 16.

Is Vercel more secure than OVH or AWS hosting?

Vercel reduces certain risks specific to Next.js, because the platforform is designed for this frameworrk and some reviews indicate unaffected Vercel deployments. OVHcloud, AWS, or Scaleway remain possible, but require more expertise with Node.js, CDN, proxy, logs, and updates.

How much does a Next.js security audit cost?

For a targeted review before launch, often plan for around €1,500 to €4,000 before tax in France. An application with user accounts, personal data, or payment generally requires a higher budget.