SafeLine is a self-hosted WAF and reverse proxy from chaitin/SafeLine that filters malicious HTTP/S traffic, protecting authorized web applications from SQL injection, XSS, and bot abuse.

Most tools we cover here are picks, lockpicks, and scanners — things that find the hole. SafeLine, published by chaitin/SafeLine, is the opposite: it is the thing standing in the hole. Written in Go, licensed under GPL-3.0, and sitting at over 22,600 stars, it is a self-hosted Web Application Firewall and reverse proxy that positions itself between the Internet and your web application, inspecting every HTTP/S conversation before it reaches origin. For blue-team operators tired of cobbling together ModSecurity rulesets, this is a serious, actively maintained alternative with a management UI rather than a config-file archaeology project.

The architectural model is classic reverse-proxy interception, and the README explains it plainly. A proxy server protects a client by interposing an intermediary; a WAF inverts that relationship, protecting the server by forcing all clients to pass through the firewall first. SafeLine filters, monitors, and blocks malicious HTTP/S traffic inbound, and — a detail worth noting — also aims to prevent unauthorized data from leaving the application, giving it some exfiltration-pressure value beyond pure inbound blocking. Decisions are driven by policies that classify traffic as malicious or safe, covering the standard injection family: SQL injection, XSS, code injection, os command injection, CRLF injection, ldap injection, xpath injection, RCE, XXE, SSRF, path traversal, webshells/backdoors, bruteforce, and http-flood.

The README condenses the capability set into five core pillars: defenses for web attacks, proactive bot-abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web Access Control List. That second and third pillar are where SafeLine differentiates from a plain rules engine. The Anti-Bot Challenge presents interactive captcha-style challenges so human users pass while crawlers and bots get blocked — the README includes animated showcases of exactly this interaction for both legitimate and malicious visitors. The Authentication Challenge goes further, requiring a shared password before a visitor is even allowed to see the application, effectively giving you a cheap zero-trust gate in front of staging environments or admin panels.

Dynamic Protection is the most interesting feature from a defensive-engineering standpoint. When enabled, the HTML and JavaScript served by your origin are dynamically encrypted on each visit, so a scraper or attacker pulling your pages gets obfuscated markup that still renders correctly for a real browser session. Both HTML and JS variants are demonstrated in the README's showcase matrix. This is tamper-resistant delivery rather than a security boundary in itself, but it meaningfully raises the cost of automated content theft and client-side reconnaissance against protected applications, and it composes well with the bot challenge.

Rate limiting rounds out the abuse controls, defending against DoS attacks, bruteforce attempts, traffic surges, and other volume-based abuse by throttling anything exceeding defined limits. Combined with the web ACL, this gives operators layered, policy-driven control: signature-based detection for the injection classes, behavioral challenges for bots, volume thresholds for floods, and explicit allow/deny semantics for known-bad or known-good sources. The showcase table in the README maps each feature to its visible outcome — blocked-for-attack-detected, blocked-for-access-too-fast, captcha interstitials, auth prompts, and encrypted page source — which is a refreshingly concrete way to communicate what a control actually does at the client.

The README also publishes an effectiveness evaluation against alternatives, and the numbers deserve scrutiny rather than blind acceptance. Across 33,669 samples, ModSecurity at level 1 detected 69.74% with a 17.58% false-positive rate; CloudFlare free tier detected only 10.70% with a near-zero false-positive rate; SafeLine in balance mode detected 71.65% with a 0.07% false-positive rate, and in strict mode reached 76.17% detection at 0.22% false positives. Self-reported benchmarks always carry caveats — sample composition is unknown — but the headline is the false-positive discipline: matching or beating ModSecurity detection while cutting false positives by two orders of magnitude is the difference between a WAF you can run in blocking mode and one you quietly set to log-only.

Maturity claims are unusually strong for an open-source security project. The project states it is production-ready, citing over 400,000 installations worldwide, more than 1,000,000 protected websites, and over 30,000,000,000 HTTP requests handled daily. It has trended at number one on GitHub, is listed in awesome-selfhosted, was rated 10.0/10 by HelloGitHub, and features on Product Hunt. Community infrastructure includes an active Discord with staff-identified core team members, dedicated #feedback and #FAQ channels, and GitHub issues. For an operator evaluating whether to bet a production edge on this, the install base and response channels matter as much as the feature list.

Deployment is deliberately boring: installation instructions live in the official Install Guide, and application onboarding is documented under Configuration — you add the backend application you want protected and SafeLine fronts it as a reverse proxy. A live demo is available for evaluation before committing, which is the right way to kick the tires on detection behavior and the management UI against your own test traffic. The README carries a warning for mainland-China users that the international edition may fail to reach cloud services, pointing to separate Chinese documentation — a hint that some components phone home to vendor cloud services, which you should factor into your deployment threat model and egress rules.

The ecosystem integrations are what push this from standalone appliance to platform. There is a SafeLine MCP Server for AI-assisted management and control, an Ingress-NGINX plugin for protecting Kubernetes ingress traffic, and a Kong Gateway plugin for protecting APIs and services. The Kubernetes path is particularly relevant for teams running microservices who want WAF coverage without re-architecting; the Kong plugin extends the same detection to API estates. The MCP integration is a sign of where security tooling management is heading — natural-language driven policy tuning — though operators should treat any AI-driven control plane with the same change-management discipline as manual edits.

There is a commercial tier — SafeLine PRO with published plans, pricing, and a 7-day trial — but the community edition is genuinely functional and self-hosted under GPL-3.0. Read the LICENSE.md carefully for the exact boundary between the open-source core and paid features, especially if you are redistributing or embedding it in a service offering, since GPL-3.0 obligations apply to the covered components.

For the offensive-security professionals who make up most of this blog's audience, SafeLine is valuable in the other direction: it is the wall you will meet. Standing it up in a lab against your own target applications, then running your authorized assessments against it, tells you exactly what its detection profile looks like — where 71–76% detection means a quarter of classic payload classes pass through, and where the strict mode's false-positive cost sits. Understanding the defender's instrumentation makes you a better attacker in authorized engagements, and understanding this particular defender, given a million websites behind it, is rapidly becoming baseline tradecraft knowledge.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.