Coder Legion - Recent posts tagged flask

How to Protect a Flask or Django App When the WAF Is a Reverse Proxy

Wed, 28 Oct 2026 02:30:19 +0000

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.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Decide If a Flask or Django App Needs a WAF

Wed, 28 Oct 2026 02:29:47 +0000

Protecting a Flask or Django application with a WAF is a placement decision, not a framework-plugin decision. The SafeLine introduction describes a self-hosted web application firewall that filters and monitors HTTP traffic between a web application and the Internet (https://docs.waf.chaitin.com/en/home). Those pages do not name Flask, Django, WSGI, or ASGI, and they do not document a Python package, middleware class, or SDK. If the requirement is an in-process integration, these sources do not support that promise. What they do support is a reverse-proxy checklist: confirm the host, put inspection in front of the existing process, forward only accepted traffic upstream, and prove a block before calling the app protected.

SafeLine is documented as an HTTP and HTTPS reverse proxy developed on nginx. It receives traffic for the original site, cleans malicious attack traffic, and forwards safe traffic to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). The same introduction distinguishes this from a forward proxy. A forward proxy hides a client. This WAF sits in front of the server so clients pass through it before they reach the application (https://docs.waf.chaitin.com/en/home). For Python, the useful reading is narrow. The Flask or Django process remains the upstream. The language of that process is not a documented configuration field.

Placement checks

Start with exposure, not with application code. In the web console, adding an application asks for Domain, Port, and Upstream. Domain may be a domain name, a hostname, or an IP address. Port is the port SafeLine listens on, such as 80 or 443, and HTTPS applications need the SSL option checked. Upstream is the real address of the original app, which is where traffic goes after inspection. After those fields are saved, the domain you entered must resolve to the IP of the server running SafeLine (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). That is the documented protection path. It does not include editing a Django settings module, registering a Flask before-request hook, or installing a Python dependency.

Treat any assumption about process managers as out of scope. The sources do not require gunicorn, uWSGI, or a particular application server. They require a reachable upstream address. Keep the Python process on the address you enter, and do not invent header, health-check, or load-balancing behavior that the application guide never states.

Host checks

Run the host checklist before telling anyone the app is covered. The deploy guide requires Linux, x86_64 or arm64, Docker 20.10.14 or above, and Docker Compose 2.0.0 or above. The minimum environment is 1 CPU core, 1 GB of memory, and 5 GB of disk, and the CPU must support ssse3 (https://docs.waf.chaitin.com/en/GetStarted/Deploy). An ARM server has a further constraint in that same guide: SafeLine installed on ARM requires a Pro license to work properly, and the Personal Edition is not supported on ARM. If any item fails, stop. A Python app behind an unfinished install is not a protected app.

What you can claim

Map documented detections to the routes you actually expose, and leave unsupported claims off the list. The introduction lists defenses for SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse. Its 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). The feature list adds rate limiting for DoS attacks, brute-force attempts, traffic surges, and other abuse by throttling traffic that exceeds defined limits. It also describes a CAPTCHA challenge that allows human users while blocking crawlers and bots, an authentication challenge that blocks visitors who do not enter the password, and dynamic protection that encrypts HTML and JS on each visit (https://docs.waf.chaitin.com/en/home).

Those controls can sit beside a Python app, but they are not framework fixes. SQL injection filtering does not replace parameterized queries. XSS filtering does not replace template escaping. Path-traversal and command-injection filtering do not replace safe file and process handling. Rate limiting can sit in front of a login route, but the supplied documents do not publish a Flask-specific or Django-specific threshold, so this checklist must not invent one. The authentication challenge is easy to misread. It is a visitor password gate, not a Django authentication backend and not a Flask session login. Dynamic protection is documented for HTML and JS, so do not assume it rewrites a JSON response body.

What stays in the app

Keep application controls on the same checklist as proxy controls. SafeLine is described as filtering, monitoring, and blocking malicious HTTP traffic, and as preventing unauthorized data from leaving the app by applying policies that separate malicious traffic from safe traffic (https://docs.waf.chaitin.com/en/home). That is a traffic decision. Authorization bugs, weak session secrets, leaked configuration, and vulnerable dependencies can still arrive as requests that look ordinary. CSRF checks, permission checks, input validation, and secret handling stay in Flask or Django after the proxy is live.

Proof before extra controls

Verify with the cases the application guide already publishes, and only against a site you control. The examples cover SQL injection, XSS, path traversal, code injection, and XXE as query-string tests. Replace the sample domain with your own. If the blocking page appears, the guide treats that as evidence that the attack was defended. Then open the console attack list and click detail for the event (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A checklist is incomplete if the only proof is that the homepage still loads. Legitimate traffic must pass, and a known-bad request from that documented set must be recorded.

Turn on extra visitor challenges only after that path is proven. Rate limiting, CAPTCHA, the authentication challenge, and dynamic HTML and JS encryption all change what a normal user experiences. The documents describe what each control does. They do not give a Python preset or claim that one mode fits every Django admin and every Flask API. Choose the control that matches an abuse you can name: floods and brute force for rate limiting, bot traffic for CAPTCHA, a shared gate password for the authentication challenge, and HTML or JS exposure for dynamic protection. If you cannot name the abuse, leave the extra control off.

The documentation states that SafeLine is production-ready (https://docs.waf.chaitin.com/en/home). That statement does not add a Flask or Django connector, and it does not replace the checks above. Decide yes only when the host meets the deploy requirements, the application entry points at a real upstream, DNS lands on the SafeLine server, a documented attack is blocked and visible in the console, and the app still enforces its own authorization and input rules.

Does SafeLine document a Flask or Django plugin?

No. The install guide and the application guide describe deployment and an HTTP reverse proxy with Domain, Port, and Upstream. They do not document a Python package or framework middleware (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Do not plan on an in-app integration that these sources never describe.

Where does the Python process belong?

It belongs at the upstream address. Clients should reach the domain that resolves to the SafeLine server. SafeLine listens on the configured port, inspects the request, and forwards safe traffic to the real application address (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). The framework can keep serving on the address you configured as upstream.

No. Nothing in the cited documents says a WAF replaces application authorization, template escaping, or safe query construction. Use the proxy to filter documented web attacks and abuse patterns, and keep those controls in the app (https://docs.waf.chaitin.com/en/home).

How should I test without inventing payloads?

Use the five cases published in the application guide: SQL injection, XSS, path traversal, code injection, and XXE. Point them at your own protected domain. Expect the blocking page, then confirm the event in the console attack list and open its detail (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

The authentication challenge. When it is turned on, visitors must enter the password or they are blocked (https://docs.waf.chaitin.com/en/home). That is a site gate. Flask and Django user accounts remain a separate system, and this checklist should not merge the two.

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.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

I built an independent search engine—and the results were interesting

Sat, 06 Jun 2026 13:15:32 +0000

A few months ago, I came across FrogFind, a retro search engine, and I decided that I wanted to try my hand at making one, too.

I first started with the crawler, carefully planning out a simple single threaded Python requests bot using SQLite3 that accommodated robots.txt. This was particularly difficult—I had barely any experience in the field of search engine creation, and its subcategories.

After the crawler was the webapp, which was relatively easy, because of my experience with Flask. I used Redis for rate limit storage, and various algorithms to do the searching for me.

I shoved my crawler and webapp into a pip package, quokko, with a CLI to control it. I wanted my project to be accessible, and for people to create their own search engines without trouble.

Hosting it, as of Jun 6, 2026, there are around 13 million entries, which is very little for a search engine. The engine's quality may not be ideal, but it seems to provide me all these curious corners of the Internet, and also seems to be a tad more unfavourable to companies in the Big Tech category.

PROJECT HAS BEEN CLOSED DUE THE THE HASSLE OF HOSTING IT. . . SORRY!

It's now hosted here: quokko.splot.dev
And you'll find the code and documentation here: https://codeberg.org/splot-dev/quokko

This is a hobby project; errors are inevitable.

Its simple customizability allows for people to make their own micro search engines, and the goal is for these micro search engines to form a net of niche, curious alternative human knowledge collections.

The goal of Quokko is not to become a competitor search engine, but for it to be the open door for more other search engines.

When to Choose FastAPI Over Django or Flask: A Comprehensive Guide with Practical Examples

Wed, 22 Jan 2025 10:22:44 +0000

Python is home to several powerful web frameworks, each designed to cater to different needs. Django and Flask have long been dominant players, offering solutions for web development for over a decade. However, in recent years, FastAPI has emerged as a modern framework, purpose-built for APIs and asynchronous programming. Its speed, simplicity, and robust features make it an appealing choice for developers.

In this guide, we’ll explore:

What makes FastAPI unique.
Key differences compared to Django and Flask.
Specific use cases where FastAPI excels.
Detailed examples demonstrating its strengths.

What is FastAPI?

FastAPI is a Python framework for building APIs with modern design principles. It’s built on the Starlette framework (for the web parts) and Pydantic (for data validation). Unlike Django or Flask, FastAPI fully embraces asynchronous programming with asyncio, making it one of the fastest Python frameworks available.

Key Features:

High Performance: Comparable to Node.js and Go, thanks to ASGI and
async support.
Automatic Documentation: Swagger UI and ReDoc are auto-generated.
Type Safety: Input validation and response types are built-in using
Python's type hints.
Ease of Use: FastAPI is simple to use, even for beginners, while
offering powerful capabilities for experts.

Why Choose FastAPI?

FastAPI is specifically designed for building modern APIs with a focus on performance and developer experience. Let’s delve deeper into scenarios where it outshines Django and Flask:

1. High-Performance APIs
If your application needs to handle thousands of simultaneous requests efficiently, FastAPI is a game-changer.

Built on ASGI, it supports asynchronous requests out of the box.
Ideal for real-time applications, such as chat servers, streaming
platforms, or IoT systems.

Example: Asynchronous API with FastAPI

from fastapi import FastAPI
import asyncio

app = FastAPI()

@app.get("/long-task/")
async def long_task():
      await asyncio.sleep(5)  # Simulate a time-consuming operation
      return {"message": "Task completed after 5 seconds"}

This endpoint:

Demonstrates how FastAPI handles concurrent requests without blocking
other users.
Would be cumbersome to implement in Flask or Django without
significant modifications.

2. Automatic Documentation

FastAPI automatically generates Swagger UI and ReDoc documentation for your API. This is a huge time-saver for teams working on complex APIs.

Example: Auto-Generated Docs

from fastapi import FastAPI

app = FastAPI()

@app.get("/items/{item_id}")
async def read_item(item_id: int, q: str = None):
"""
Fetch an item by ID.

  - **item_id**: The ID of the item to fetch.  
  - **q**: An optional query string for filtering results.  
"""
    return {"item_id": item_id, "query": q}

To access the docs:

Run the app using uvicorn:

uvicorn main:app --reload

Visit:

Swagger UI: http://127.0.0.1:8000/docs
ReDoc: http://127.0.0.1:8000/redoc

Both provide an interactive interface to test your API endpoints.

3. Data Validation and Serialization

FastAPI uses Pydantic for data validation, which ensures robust type checking and error handling.

Example: Input Validation with Pydantic

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class User(BaseModel):
    username: str
    email: str
    age: int

@app.post("/users/")
async def create_user(user: User):
    return {"message": "User created successfully!", "user": user}

What happens here:

FastAPI automatically validates that the username, email, and age
fields are present and of the correct type.
If validation fails, the API returns a detailed error message
without any extra coding.

4. WebSocket Support

Real-time communication is a breeze with FastAPI, thanks to native WebSocket support.

Example: Building a WebSocket Chat Server

from fastapi

import FastAPI, WebSocket

app = FastAPI()

@app.websocket("/ws")
async def websocket_endpoint(websocket: WebSocket):
    await websocket.accept()
    while True:
        data = await websocket.receive_text()
        await websocket.send_text(f"You said: {data}")

Use this for:

Chat applications.
Real-time notifications or dashboards.
Multiplayer games.

5. Ease of Scaling and Deployment

FastAPI integrates well with modern deployment tools like Docker and Kubernetes. Its ASGI compatibility makes it ideal for scaling microservices.

Example: Dockerizing FastAPI

FROM python:3.10-slim

WORKDIR /app
COPY requirements.txt requirements.txt
RUN pip install -r requirements.txt
COPY . .

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

When Django or Flask Might Be Better

Django is unbeatable for full-stack applications with templates,
authentication, and ORM out of the box.
Flask is perfect for small projects or when you need a quick
prototype without the complexity of Django or FastAPI.
Legacy Systems: If your team already uses Django or Flask
extensively, switching to FastAPI might not justify the learning
curve.

Tip: When starting with FastAPI, use Uvicorn as your ASGI server for a smooth development experience. It’s lightweight, easy to configure, and perfectly complements FastAPI’s capabilities.

Caution: If you are migrating from Django or Flask to FastAPI, note that FastAPI does not come with built-in components like an ORM (similar to Django’s) or a templating engine. Be prepared to integrate libraries like SQLAlchemy or Jinja2 for those functionalities.

Note: FastAPI’s auto-generated documentation supports both Swagger UI and ReDoc. These are especially useful for teams collaborating on API development as they provide an interactive interface for testing endpoints directly.

FAQ Q: Is FastAPI better than Django and Flask for all use cases? A: Not necessarily. While FastAPI is excellent for APIs and asynchronous programming, Django is better suited for full-stack applications, and Flask is ideal for lightweight, quick prototypes.

Q: Does FastAPI support databases out of the box? A: No, FastAPI doesn’t include a built-in ORM. However, you can easily integrate libraries like SQLAlchemy, Tortoise ORM, or GINO for database support.

Q: How does FastAPI handle validation errors? A: FastAPI uses Pydantic for validation and automatically generates detailed error messages for invalid data inputs, saving developers significant time.

Q: Can I use FastAPI for real-time features like WebSockets? A: Yes, FastAPI has built-in support for WebSockets, making it a great choice for real-time applications such as chat systems and live dashboards.

Q: What’s the best way to deploy FastAPI applications? A: FastAPI integrates well with Docker for containerization and Kubernetes for scaling. Use an ASGI server like Uvicorn or Daphne for production deployment.

Conclusion

FastAPI excels in modern, API-driven development, offering unparalleled performance, automatic documentation, and type safety. While Django and Flask still shine in specific scenarios, FastAPI is the future of Python APIs, designed for speed and scalability.

Ready to start? Install FastAPI today and see how it transforms your API development!

pip install fastapi uvicorn