Python teams usually start web security inside the framework. Django has auth, CSRF middleware, and an ORM. Flask has signed sessions, request hooks, and whatever validators you added. Those controls still matter. They are not the same thing as a web application firewall sitting on the HTTP path. If the question is how to protect a Python web app such as Flask or Django with a WAF, the SafeLine documents support a placement decision, not a language plugin. SafeLine is a self-hosted WAF that filters and monitors HTTP traffic between a web application and the Internet, and it works as a reverse proxy so clients reach the WAF before they reach the server (https://docs.waf.chaitin.com/en/home). The application guide says the same thing in operational terms: SafeLine receives traffic for the original site, cleans malicious traffic, and forwards safe traffic to the upstream application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Those pages do not describe a pip package, a Flask extension, or a Django middleware setting. Do not invent that integration. Decide whether a reverse-proxy shield fits the app you already run.
Start with the entry path, not the view function. Write down the public hostname, the port clients use, and the real upstream that should stay private. In the SafeLine console, an application record takes a domain, hostname, or IP, a listen port such as 80 or 443, and an upstream address. HTTPS apps use the SSL option (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). After that, the domain must resolve to the SafeLine server. A Gunicorn process, a uWSGI socket, or an existing origin Nginx can remain the upstream. The change is that the public door moves. If a load balancer already terminates TLS, map that hop explicitly. Two public doors means the proxy is optional, and an optional WAF does not protect the app.
Then check the host before you promise a cutover. The deploy guide requires Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, a CPU with ssse3, and at least 1 core, 1 GB of memory, and 5 GB of disk (https://docs.waf.chaitin.com/en/GetStarted/Deploy). The same page states that a SafeLine install on ARM requires a Pro license and that the Personal Edition is not supported on ARM. A small Flask demo on a laptop does not waive those constraints. If the host fails the check, fix the platform first. Filtering rules will not help if the proxy cannot run.
Match the documented attack list to routes you actually expose. The introduction names SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, bruteforce, HTTP flood, and bot abuse (https://docs.waf.chaitin.com/en/home). A Django admin search box, a Flask query parameter, a file download, and a webhook that fetches a URL are different code paths, but they are still HTTP. The proxy is useful because it inspects that traffic before the view runs. It is not useful as a substitute for parameterized queries, template escaping, or a view that shells out to a user-controlled string. Keep those fixes in the app.
The same introduction lists core capabilities beyond signature-style blocking: defenses for web attacks, 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). The feature list then describes rate limiting for traffic that exceeds defined limits, including DoS, bruteforce attempts, traffic surges, and other abuse. It also describes a CAPTCHA challenge intended to allow human users while blocking crawlers and bots, an authentication challenge that requires a password, and dynamic protection that encrypts HTML and JS on each visit when it is turned on. Treat those as perimeter switches in the WAF, not as Django settings or Flask blueprints. The supplied pages do not document numeric thresholds, so do not copy invented limits into a runbook. Turn a control on, watch real traffic, and keep the strictest control off any path you have not tested.
A published evaluation on 33,669 samples is the only benchmark figure these sources provide. In that table, the SafeLine Balance row shows 71.65% detection, a 0.07% false positive rate, and 99.45% accuracy. The SafeLine Strict row shows 76.17% detection, a 0.22% false positive rate, and 99.38% accuracy (https://docs.waf.chaitin.com/en/home). Use the table as a published comparison, not as a guarantee for your login form or JSON API. The Strict row detects more and also shows a higher false positive figure. That is a reason to replay ordinary browser flows, API clients, and file uploads after any policy change.
Prove the proxy with your own hostname. The application guide publishes sample probes for SQL injection, XSS, path traversal, code injection, and XXE, and it says a block page means the attack was stopped. Details then appear in the console attack list (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Run those patterns only against an application you are authorized to test, with the sample host replaced by your domain. A block proves the request passed through SafeLine. It does not prove that every Django permission check or Flask webhook is correct. Follow with a clean login, a normal form post, and a known-good API call. If a legitimate request is blocked, inspect the detail view before you weaken the whole site.
The decision is complete when four statements are true. The app is reached over HTTP or HTTPS. One public name points at SafeLine, and the upstream is the real Flask or Django origin. The host meets the documented minimums, including the ARM license note if that architecture applies. Someone owns the attack list after cutover. If one statement is false, harden the Python app and wait. A reverse proxy is the supported path. A framework plugin is not.
Does SafeLine ship a Flask or Django integration?
No. The install and application guides describe a reverse-proxy WAF with a domain, a listen port, and an upstream. They do not document a Python package or a framework setting (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).
Which request classes should a Python team map first?
Start with the attacks named in the product introduction: SQL injection, XSS, code injection, command injection, SSRF, path traversal, bruteforce, HTTP flood, and bot abuse are the ones most teams can map to a route (https://docs.waf.chaitin.com/en/home).
Are rate limiting and CAPTCHA part of the app code?
No. Rate limiting, CAPTCHA challenge, authentication challenge, and dynamic HTML and JS protection are WAF features described on the product page (https://docs.waf.chaitin.com/en/home). Keep CSRF, sessions, and permissions in Flask or Django.
What proves the cutover worked?
Point the domain at the SafeLine server, replay the documented probe patterns against your own site, expect a block page, and open the attack detail in the console (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Then confirm normal user and API traffic still passes.
What host checks are mandatory?
Linux, x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, ssse3, and at least 1 CPU core, 1 GB memory, and 5 GB disk. ARM also requires a Pro license, and the Personal Edition is not supported there (https://docs.waf.chaitin.com/en/GetStarted/Deploy).
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.