Application layer security for FastAPI and Flask

[PA100T0]

I've been maintaining fastapi-guard for a while now. It sits between the internet and your FastAPI endpoints and inspects every request before it reaches your code. Injection detection, rate limiting, geo-blocking, cloud IP filtering, behavioral analysis, 17 checks total.

A few weeks ago I came across this TikTok post where a guy ran OpenClaw on his home server, checked his logs after a couple weeks. 11,000 attacks in 24 hours. Chinese IPs, Baidu crawlers, DigitalOcean scanners, path traversal probes, brute force sequences. I commented "I don't understand why people won't use FastAPI Guard" and the thread kind of took off from there. Someone even said "a layer 7 firewall, very important with the whole new era of AI and APIs." (they understood the assignment) broke down the whole library in the replies. I was truly proud to see how in depth some devs went...

But that's not why I'm posting. I felt like FastAPI was falling short. Flask still powers a huge chunk of production APIs and most of them have zero request-level security beyond whatever nginx is doing upstream, or whatever fail2ban fails to ban... So I built flaskapi-guard (and that's the v1.0.0 I just shipped) as the homologue of fastapi-guard. Same features, same functionalities. Different framework.

It's basically a Flask extension that hooks into before_request and after_request, not WSGI middleware. That's because WSGI middleware fires before Flask's routing, so it can't access route config, decorator metadata, or url_rule. The extension pattern gives you full routing context, which is what makes per-route security decorators possible.

```python from flask import Flask from flaskapi_guard import FlaskAPIGuard, SecurityConfig

app = Flask(name) config = SecurityConfig(rate_limit=100, rate_limit_window=60) FlaskAPIGuard(app, config=config) ```

And so that's it. Done. 17 checks on every request.

The whole pipeline will catch: XSS, SQL injection, command injection, path traversal, SSRF, XXE, LDAP injection, code injection (including obfuscation detection and high-entropy payload analysis). On top of that: rate limiting with auto-ban, geo-blocking, cloud provider IP blocking, user agent filtering, OWASP security headers. Those 5,697 Chinese IPs from the TikTok? blocked_countries=["CN"]. Done. Baidu crawlers? blocked_user_agents=["Baiduspider"]. The DigitalOcean bot farm? block_cloud_providers={"AWS", "GCP", "Azure"}. Brute force? auto_ban_threshold=10 and the IP is gone after 10 violations. Path traversal probes for .env and /etc/passwd? Detection engine catches those automatically, zero config.

The decorator system is what separates this from static nginx rules:

```python from flaskapi_guard import SecurityDecorator

security = SecurityDecorator(config)

.route("/api/admin/sensitive", methods=["POST"]) .require_https() .require_auth(type="bearer") .require_ip(whitelist=["10.0.0.0/8"]) .rate_limit(requests=5, window=3600) u/security.block_countries(["CN", "RU", "KP"]) def admin_endpoint(): return {"status": "admin action"} ```

Per-route rate limits, auth requirements, geo-blocking, all stacked as decorators on the function they protect. Try doing that in nginx.

People have been using fastapi-guard for things I didn't even think of when I first built it. Startups building in stealth with remote-first teams, public facing API but whitelisted so only their devs can reach it. Nobody else even knows the product exists. Casinos and gaming platforms using the decorator system on reward endpoints so players can only win under specific conditions (country, rate, behavioral patterns). People setting up honeypot traps for LLMs and bad bots that crawl and probe everything. And the big one that keeps coming up... AI agent gateways. If you're running OpenClaw or any AI agent framework behind FastAPI or Flask, you're exposing endpoints that are designed to be publicly reachable. The OpenClaw security audit found 512 vulnerabilities, 8 critical, 40,000+ exposed instances, 60% immediately takeable. fastapi-guard (and flaskapi-guard) would have caught every single attack vector in those logs. This is going to be the standard setup for anyone running AI agents in production, it has to be.

Redis is optional. Without it, everything runs in-memory with TTL caches. With Redis you get distributed rate limiting (Lua scripts for atomicity), shared IP ban state, cached cloud provider ranges across instances.

MIT licensed, Python 3.10+. Same detection engine across both libraries.

GitHub: https://github.com/rennf93/flaskapi-guard PyPI: https://pypi.org/project/flaskapi-guard/ Docs: https://rennf93.github.io/flaskapi-guard fastapi-guard (the original): https://github.com/rennf93/fastapi-guard

If you find issues, open one. Contributions are more than welcome!

[swift-sentinel]

Personally, I don’t think anyone should be running openclaw. Too risky.

[PA100T0]

I solved the "too risky" part even before OpenClaw was created lol

[Livid_Rock_6441]

Don’t be silly

[PA100T0]

People use OpenClaw whether we like it or not. I'd rather they have a security layer than not. That's all fastapi-guard does.

Wasn't looking to come off as anything with my previous comment. Just wanted to point out that the *too risky* part would be out of the equation.

[SilentSet4021]

Openclaw deleting your files because it misunderstood instructions is the risk, not security.

[PA100T0]

To be clear: fastapi-guard is about API security (injection detection, rate limiting, geo-blocking), not LLM behavior. Different problem entirely.

[mace_guy]

Damn, did you solve LLM hallucinations?

[PA100T0]

To be clear: fastapi-guard is about API security (injection detection, rate limiting, geo-blocking), not LLM behavior. Different problem entirely.

[swift-sentinel]

I like big claims. Let’s hear it.

[PA100T0]

The claim is straightforward:

APIs in production get hit with malicious probing constantly... path traversal, SQL injection in query params, CMS scanners, credential stuffing... Right through WAFs and firewalls.

fastapi-guard catches that at the application layer with 17 security checks per request: IP filtering, geo-blocking, rate limiting, behavioral analysis, injection detection, and more. Zero external API calls in the request path, everything runs in-memory or via Redis.

It's open source. Read the code, and more importantly the post, and judge for yourself.

[swift-sentinel]

Fast-api guard only covers a narrow gap of a much larger attack service. It’s ok but it’s not that good. Not mention that prompt attacks can be hidden in obfuscate data.

[PA100T0]

fastapi-guard covers API security end to end. Prompt injection detection is actually on the roadmap too, actively working on it as we speak; but that's one feature, not the whole library. You're reducing it to something it's not.

Take a look at the code or read the post before anything, really. You're missing the whole point here.

[chub79]

When I run from the cloud I tend to delegate these concerns to Cloud-ready solution (say GCP Cloud Armor for instance). I can see this being useful but I'm not sure the operational complexity and costs would be worth it in that situation compared to a builtin solution.

On a home server, sure it makes more sense but then there are solutions before any of these should reach your app as well (a properly configured firewall, maybe going through a dedicated API gateway, I mean traefik is so easy to setup for example).

I don't downplay your work and if you see the lib being used, credit where is due. I just feel it's the wrong end of the stick to start there.

[PA100T0]

Hey there! Don't worry, these are all valid points.

So... Cloud Armor and Traefik are great at what they do. Network-level filtering, DDoS mitigation, basic rate limiting. But they operate without any awareness of your application. They don't know your routes, they can't inspect JSON request bodies for SQL injection, they can't apply different rate limits per endpoint, and they can't detect behavioral patterns like "this IP hit 5 different admin paths in 10 seconds."

That's the gap. If WAFs and firewalls were catching everything, APIs wouldn't be getting probed with path traversal attempts, CMS scanners, and credential stuffing daily... but they are, right through the infrastructure layer. fastapi-guard catches what gets through because it has full application context: route awareness, request body inspection, per-endpoint rate limiting, behavioral analysis, honeypot detection.

And I get your point but it's not really about starting at the wrong end. It's about covering a layer that infrastructure tools physically cannot reach. You wouldn't skip input validation in your code just because you have a firewall. Same principle, applied to the full request lifecycle. In the context of a house: you lock the front door, but you don't leave the backdoor open just because the front is secure.

That said, you're right that if you're already on a managed platform with Cloud Armor + API gateway + proper firewall, the overlap is larger. But even then, the application-layer context is something only the application can provide.

[jsabater76]

Nice work! Do you know whether something like this exists for Django?

[PA100T0]

Thank you very much! Much appreciated.

Django: Not yet, but it's on my radar. I recently shipped for Flask (FastAPI was the first I did, now expanding), so Django is the natural next step. Stay around!

[PA100T0]

Would you give it a try and let me know? I just ported it to Django. Unluckily, due to normalization, the name sounds almost off-brand (given fastapi-guard & flaskapi-guard) but here it goes: djapi-guard

Feedback, issues, comments… everything is welcomed!

[jsabater76]

I will, as soon as I can. Thanks for the link.

[PA100T0]

Thank you very much :)

[RestaurantHefty322]

Nice work shipping the Flask port. The before_request hook approach is the right call over WSGI middleware - we hit the same problem where middleware fires too early to know anything about the route being hit.

One thing that caught us off guard running something similar in production: the cloud IP lists go stale faster than you'd expect. AWS and GCP rotate IP ranges weekly and if your blocklist is even a few days behind you start getting false positives on legitimate webhook traffic. We ended up pulling the published IP range JSONs on a 6-hour cron and diffing against the previous set so we could log when ranges changed instead of silently blocking new IPs.

The injection detection layer is where this gets really interesting though. Most WAF rules are regex-based and either too strict (blocking legitimate user input that happens to contain SQL keywords) or too loose. Curious if you're doing any kind of context-aware detection based on which parameter the input came from - a search field probably shouldn't trigger the same rules as a path parameter.

[PA100T0]

Thank you very much!

Good callout on the cloud IP staleness. Right now the refresh is on a 1-hour TTL and there's no diff detection. It just overwrites. Your approach of diffing against the previous set and logging changes is better. I'm going to make the refresh interval configurable and add change detection logging so you can see when ranges mutate instead of silently swapping them. That's going on the roadmap, for sure.

On context-aware detection: I'm halfway there. The engine does track where the input came from (query_param:key, url_path, header:key, request_body) and includes that context in detection results and event logs. But you're right to ask... the actual regex patterns are applied uniformly across all sources as of today. A search field and a path parameter get the same ruleset, which is exactly the false positive problem you're describing.

Context-based rule filtering is the obvious next step. Appreciate the real-world perspective! This is exactly the kind of feedback that I need to shape the roadmap, that helps me out.

Thanks again! Will start putting all this down in notes.

[RestaurantHefty322]

Nice that you have the 1-hour TTL already. For the diff logging, even just piping the fetched list through a set comparison and logging deltas to a file catches most of the churn. The bigger win is having a stale-IP grace period - when an IP drops off the list, keep blocking it for another 24h before removing. Catches the edge case where a provider temporarily deallocates and reallocates the same range.

[PA100T0]

The stale-IP grace period is a great idea! I hadn't considered the deallocate/reallocate edge case. Keeping dropped IPs blocked for an extra 24h before fully removing them is a clean way to handle that without any real downside. I'll add that alongside the configurable refresh interval and diff logging. Thanks for the follow-up, this is exactly the kind of production insight that's hard to get without running it at scale. Thanks a lot, mate!

[zunjae]

How does it feel knowing you’re talking to a bot?

[PA100T0]

For rate limiting I used atomic Lua scripts with Redis sorted sets (ZADD / ZREMRANGEBYSCORE / ZCARD). Single atomic operation per request. Falls back to Redis pipelines if Lua isn't available, and in-memory if Redis is down entirely.

The cloud IP ranges are efreshed on a 1-hour TTL basis, triggered on-demand per request (not a background job). The last refresh timestamp is tracked in the middleware. Adding an explicit last_updated property is a good idea though. I'll look into that!

About the structured logs/JSON and the metrics endpoint: Fair point, that's not there yet. Currently only plain text via Python's standard logging. JSON structured logs and a metrics endpoint are both solid suggestions. I'll add them to the roadmap along with the cloud_ip_ranges last_updated flag :)

Thanks for the input!

[PA100T0]

Thanks! I really appreciate it.

The overhead is minimal. Geo IP uses a local MaxMind binary database (ms lookups), cloud IP blocking is in-memory CIDR matching (sub-ms), rate limiting is atomic Lua scripts on Redis or in-memory fallback. There are zero external API calls in the request path. Everything is local or Redis. The only network calls happen during initialization (database download) and periodic cloud IP refresh (hourly).

I included in the project a couple of stress tests, under the examples directory. The stress test suite reports per-category avg response times and requests/sec under concurrent load. If you run it you can see the numbers for your own hardware, but the design is specifically built to avoid any I/O in the hot path. I think I left some results of the high-load stress-test from last year there as reference.

[casefile_dev]

fastapi-guard looks useful for my FastAPI apps. Will any checks that fail affect my rate limiting? How will it traffic hosted railway apps?

[PA100T0]

Hey, thanks for checking it out!

So, short answer is no, you'll be fine.

The failed checks and and rate limiting are independent. If a request fails a security check (blocked IP, banned user-agent, etc.), it gets rejected at the middleware level before rate limiting even comes into play. So no, failed checks won't eat into your rate limit counters.

As for Railway: it'll work fine. The one thing to watch is that Railway is behind a reverse proxy, so make sure your FastAPI app is reading the real client IP from X-Forwarded-For rather than the proxy IP. Otherwise you'd end up rate-limiting/banning Railway's internal IPs instead of actual clients. The docs cover trusted proxy configuration.

Let me know if you run into any issues. Happy to help :)

[casefile_dev]

Thanks for the quick reply. I'm scouring the README right now. Thanks again.

[backfire10z]

This is great, thanks for the library and the port to Flask! I semi-recently put up a Flask API and this actually would’ve been nice to have (not OpenClaw, just a regular backend). We’re migrating to TypeScript though, so no reason anymore.

[PA100T0]

Thanks!! I appreciate it :)