Security middleware
An edge-security middleware that blocks scanner traffic and slow probers before any view runs.
What it blocks
- Scanner paths —
/wp-admin,/.env,/phpmyadmin,/.git,/.aws, traversal patterns (../), SQLi/XSS payloads in the URL. - Bad user agents —
sqlmap,nikto,nuclei,masscan,acunetixand similar known scanner UAs. - 4xx flood — IPs that produce too many 4xx responses in a short window get auto-blocked.
How blocking works
When any rule fires, the IP is added to rate_limit:blocked:<ip> with a 24-hour TTL. From that moment every request from that IP returns 403 instantly, before authentication or any view code runs.
That block store is shared with BaseResource's application-layer rate limiting, so an IP blocked by the middleware is also blocked inside dispatch, and vice-versa.
4xx flood detector
Two sliding windows count 4xx responses per IP:
MAX_4XX_PER_MINUTE = 10— burst probeMAX_4XX_PER_HOUR = 30— slow probe
Either trips → block.
Pen-test history
This middleware exists because the same patterns kept showing up in real attack traffic: WordPress probes against Django, traversal scans, SQL injection attempts in URL params. Blocking on first sight cuts log noise and stops the attack before it costs anything.
The middleware is intentionally aggressive. False positives are rare on REST APIs because real clients do not visit /wp-login.php.
Custom patterns
Patterns and UAs live in zeromcp/security.py as module-level constants. Subclass the middleware to extend them in your project, or open a PR.
0-mcp by Stamatios Stamou Jr — github.com/ssjunior/0-mcp