DEV Community

Lia
Lia

Posted on

How to Protect a Next.js App with a WAF Before DNS Cutover

#nextjs #waf #proxy #checklist

A Next.js app is still a web application. Pages, Route Handlers, and server actions are reached over HTTP or HTTPS, which is the traffic a web application firewall is built to inspect. The official SafeLine documents do not describe a Next.js plugin, an npm package, or a framework-specific connector. If you cannot put a reverse proxy in front of the origin, do not treat this as a supported Next.js integration. Use the checklist below to decide whether the documented reverse-proxy model fits, then validate it before you change DNS.

Start with placement, not a framework hook

SafeLine is a self-hosted web application firewall that protects web apps by filtering and monitoring HTTP traffic between the application and the internet (https://docs.waf.chaitin.com/en/home). Deployed in front of an application, it is a reverse proxy: clients reach the WAF first, and only traffic that passes policy is forwarded to the server (https://docs.waf.chaitin.com/en/home). The configuration guide states the same model in operational terms. SafeLine receives traffic for the original site, cleans malicious requests, and forwards safe traffic to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

For a Next.js origin, that upstream is whatever already answers HTTP for the app: a Node server, a container, or an internal address your current proxy uses. It is not a special Next.js target. In the admin console, an application is defined by domain, listen port, and upstream. For HTTPS apps, enable the SSL option. After saving, resolve the domain to the SafeLine server address (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Until that DNS cutover, the WAF is not in the request path, so it cannot protect the app.

Run this checklist before cutover

Confirm the host matches the install guide: Linux, x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, at least one CPU core, 1 GB of memory, 5 GB of disk, and a CPU with the ssse3 instruction (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Automated install, manual compose setup, and the web console on port 9443 are documented there. On ARM, SafeLine requires a Pro license to work properly, and the Personal Edition is not supported on ARM (https://docs.waf.chaitin.com/en/GetStarted/Deploy).

Write down four facts before you add the application:

  • The public hostname users already use, or the hostname you will point at SafeLine.
  • The port SafeLine should listen on, typically 80 or 443.
  • Whether TLS terminates at SafeLine. If it does, check the SSL option for that application.
  • The upstream address of the Next.js server, which must stay reachable from the SafeLine host after DNS moves.

Also decide what you will not move. Health checks, preview deployments, and internal admin tools should stay off the public application unless you intend SafeLine to inspect them. A WAF in front of production does not patch dependencies, fix authorization bugs inside Route Handlers, or replace secrets management. It filters HTTP before the app sees it.

As of September 30, 2026, SafeLine surpassed 700,000 installations worldwide. SafeLine Pro annual promotional pricing is $650-$880 versus the $1,000 regular price. The product documentation describes SafeLine as production-ready, protecting over 1,000,000 websites and handling over 30,000,000,000 HTTP requests daily (https://docs.waf.chaitin.com/en/home). Those figures describe scale, not a benchmark of your Next.js routes.

Match documented controls to real routes

The feature list covers defenses for SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoors, brute force, HTTP flood, and bot abuse (https://docs.waf.chaitin.com/en/home). Core capabilities also include proactive bot-abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list (https://docs.waf.chaitin.com/en/home).

On a Next.js app, use that list as a route review, not as a claim of framework-aware rules. Query parameters and form bodies that reach a database deserve injection review. Rendered HTML and any unsanitized markup deserve XSS review. File reads and user-controlled paths deserve path-traversal review. Server-side fetches to user-supplied URLs deserve SSRF review. Login and password-reset routes are where brute force and bot abuse usually show up. Rate limiting is documented as a way to throttle traffic that exceeds defined limits, including DoS attempts, brute force, and traffic surges (https://docs.waf.chaitin.com/en/home).

Optional controls need a test window. CAPTCHA is documented to admit human users and block crawlers and bots. Authentication challenge blocks visitors who do not enter the configured password. Dynamic protection dynamically encrypts HTML and JS on each visit (https://docs.waf.chaitin.com/en/home). Because a Next.js client hydrates from the HTML and scripts the server sends, turn dynamic protection on only after you have checked page load, client navigation, and form posts. The documents do not promise that this control is transparent to every client bundle.

A published evaluation on 33,669 samples reports SafeLine Balance at 71.65% detection, 0.07% false positives, and 99.45% accuracy, and SafeLine Strict at 76.17% detection, 0.22% false positives, and 99.38% accuracy (https://docs.waf.chaitin.com/en/home). Treat those as documented evaluation results. Re-test your own routes, especially authenticated pages and large POST bodies, before you call the deployment done.

Prove blocking and prove the app still works

The application guide includes sample probes for SQL injection, XSS, path traversal, code injection, and XXE. Replace the example domain with yours. A blocking page means SafeLine stopped that request. Open the console attack list and click detail to confirm the event was recorded (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Then load ordinary pages, static assets, and a real form. A WAF that blocks the lab probes but breaks navigation is not finished.

If those probes never hit SafeLine, stop and fix placement. Common causes are DNS still pointing at the origin, the upstream address pointing at the wrong port, or TLS being terminated somewhere that bypasses the WAF. None of those are Next.js bugs. They are path problems, and the documented model only protects traffic that actually arrives at the proxy.

Does SafeLine ship a Next.js integration?

No integration of that kind is described in the install or application guides. Protection means adding an application in the console, setting domain, port, and upstream, and sending client traffic through SafeLine first (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

Can I protect only the API routes?

The documented application object is a domain and port in front of one upstream, not a per-route Next.js selector. If API and pages share that hostname, they share the proxy. Split them only if you already serve them on different hostnames or ports that you can proxy separately.

Should I enable dynamic protection on day one?

Not until you test it. Dynamic protection encrypts HTML and JS on each visit (https://docs.waf.chaitin.com/en/home). Verify hydration, client-side navigation, and asset loading before you leave it on for a Next.js app.

How do I know the cutover worked?

A documented attack probe should show the blocking page, and the same event should appear in the attack list detail view (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A normal page load should still succeed through the same hostname.

What does the WAF not replace?

It does not patch packages, fix missing authorization, or store secrets. It filters and monitors HTTP in front of the app, and it can rate-limit, challenge bots, require an authentication password, and encrypt HTML and JS when those controls are turned on (https://docs.waf.chaitin.com/en/home). Keep application fixes in the Next.js codebase.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

Top comments (0)