I stopped treating controller middleware as the outer edge of a Laravel app after I mapped what actually happens to an HTTP request. Form Requests, CSRF tokens, authentication, policies, and the query builder all run after PHP has already accepted the connection. A web application firewall is a different layer. SafeLine is a self-hosted WAF that filters and monitors HTTP traffic between a web application and the Internet. Deployed in front of the app, it is a reverse proxy: clients pass through it before they reach the origin, and it blocks malicious HTTP and HTTPS traffic while also aiming to prevent unauthorized data from leaving the app (https://docs.waf.chaitin.com/en/home). The application guide describes the same flow. SafeLine is built on nginx, receives traffic for the original site, cleans malicious traffic, and forwards the remaining traffic upstream (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).
Those pages do not describe a Laravel package, a Composer dependency, an Artisan command, or a PHP-FPM module. If the search is really "how to protect a Laravel app with a WAF," the supported answer is a placement decision, not a framework plugin. Keep the in-app controls. Add the proxy only if you can put it on the public path and test it.
I use five checks before I change DNS.
The app must be reachable over HTTP or HTTPS, and I must be able to name an upstream. In the console, Add Application asks for a domain, a listen port such as 80 or 443, and the real upstream address. HTTPS apps use the SSL option in that dialog (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). There is no documented Laravel-specific certificate workflow, so I treat TLS as part of the proxy setup and verify it on a staging hostname first.
DNS has to move with the proxy. After the application is saved, the domain should resolve to the SafeLine server (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). If the PHP host is still reachable on the same public port, a client can skip the shield. The checklist item is blunt: one public path, through the proxy.
The host has to meet the published minimums before I talk about policy. SafeLine expects Linux on x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk. The CPU needs the ssse3 instruction (https://docs.waf.chaitin.com/en/GetStarted/Deploy). An ARM install requires a Pro license; the Personal Edition is not supported on ARM (https://docs.waf.chaitin.com/en/GetStarted/Deploy). A small PHP container is not automatically a valid SafeLine host.
I also decide which extra controls are in scope, and I leave them off until staging agrees. Documented capabilities are web-attack defense, proactive defense against what the docs call bot abused, HTML and JS code encryption, IP-based rate limiting, and a web access control list (https://docs.waf.chaitin.com/en/home). Rate limiting throttles traffic over defined limits, including DoS attempts, brute-force attempts, traffic surges, and other abuse. A CAPTCHA challenge is documented to admit human users while blocking crawlers and bots. An authentication challenge blocks visitors who do not enter the configured password. Dynamic protection encrypts HTML and JS on each visit (https://docs.waf.chaitin.com/en/home). None of those controls is a Laravel middleware alias. An IP limit can catch a shared office, a mobile carrier, or a webhook sender. A password wall is not Laravel login. Encrypting HTML and JS on every visit can disturb a page that depends on client-side scripts, and the docs do not publish a Blade or Vite matrix, so I do not assume one.
Finally, I need a place to read blocks. The guide says to watch for the blocking page, then open the console attack list and the event detail (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A block I cannot explain is a reason to narrow the change, not a reason to cut over production.
The rollout itself stays small. Confirm the host, then use the documented installer or the manual Compose path. The console is served at https://:9443/, and the initial admin account comes from docker exec safeline-mgt resetadmin (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Add the Laravel site with domain, port, and upstream. Point DNS at that host only after staging probes look right. The guide lists sample requests for SQL injection, XSS, path traversal, code injection, and XXE; replace the documentation domain with yours (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Then run ordinary Laravel traffic: login, logout, CSRF form posts, pagination, and any webhook or upload route you actually ship. The documented attack categories also include OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, SSRF, backdoor activity, brute force, and HTTP flood (https://docs.waf.chaitin.com/en/home). Those names are a coverage list, not a claim that every Laravel route will be labeled the same way.
The home page also publishes an effect evaluation on 33,669 samples. In that table, SafeLine Balance is listed at 71.65% detection, 0.07% false positives, and 99.45% accuracy. SafeLine Strict is listed at 76.17% detection, 0.22% false positives, and 99.38% accuracy. The same table includes ModSecurity Level 1 and a CloudFlare Free row (https://docs.waf.chaitin.com/en/home). I read that as a published comparison, not as a benchmark of my routes, headers, or file uploads.
The documentation calls SafeLine 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). 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. Neither the install count nor the price changes the architecture. The proxy still has to sit on the only public path, and the Laravel test plan still has to pass.
Does SafeLine include a Laravel package?
No package, middleware bridge, or Artisan integration is described in the install or application guides. Protection means proxying the domain to an upstream (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).
Should I remove Laravel validation because a WAF is in front?
No. Validation, CSRF, authentication, and authorization still enforce application rules after a request is forwarded. The WAF does not know which field is a price, which user owns a record, or which query you intended to parameterize.
Which traffic should never be tested only inside PHPUnit?
Probe the public hostname with the documented attack samples and confirm the blocking page, then confirm the event in the console (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A unit test never shows whether DNS still bypasses the proxy.
What should stay disabled until a staging pass?
Turn on IP rate limiting, CAPTCHA, the authentication challenge, and HTML or JS dynamic protection only after login, forms, and script-heavy pages still work. The docs describe what those controls do, not how a specific Laravel front end will react (https://docs.waf.chaitin.com/en/home).
How do I know the origin is actually shielded?
Resolve the domain to the SafeLine server and make sure clients cannot reach the same application on a direct public port. Then compare a blocked probe with a normal page load in the attack list (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).
If you are making the same call for a Laravel app, start with one staging site, keep the framework controls, and cut DNS only after the block list matches the probes you expect. You can review the project at https://github.com/chaitin/SafeLine and the docs at https://docs.waf.chaitin.com/en/home. For the current Pro promotion, visit https://cyberserval.tech/landing/lto.
