about: Add application-layer security (rate limiting, request inspection) as documented hardening
title: "Docs: hardening-for-production section (rate limiting + payload inspection) and optional opt-in middleware"
labels: documentation
Disclosure first: I maintain fastapi-guard, a FastAPI security middleware, so I have an affiliation here — please judge the suggestion on its merits. I'm deliberately proposing a docs-first option that treats every library (including mine) equally.
What I found
This template is the starting point for a huge number of production FastAPI deployments, and it does auth, DB migrations and Docker orchestration well. On the application-layer request-security side it currently ships only CORSMiddleware (backend/app/main.py:27-28), and the README doesn't mention rate limiting or request inspection anywhere. #307 ("How to use api rate limit") was answered with "follow the slowapi docs" — which is the right per-question answer, but it means every deployer rediscovers the same wire-up by hand.
What's missing isn't auth (the template has JWT with refresh, that's solid) — it's the perimeter questions the template currently doesn't address:
- Rate limiting — no ceiling on
/login (credential stuffing), /signup, or any API route; nothing per-IP or per-user.
- Request inspection — nothing scans request content for injection/traversal shapes before handlers run, and no recon handling for the scanner noise every public deployment gets (
/.env, /wp-login.php, ...).
- Per-route policy — one global posture for all routes, no way to say "login is tighter than the rest".
These are the gaps every template consumer eventually fills themselves — or doesn't.
Proposal (two options, both opt-in and default-off)
Option 1 — docs only (my ask). A short "Hardening for production" section in the README or development.md covering rate limiting + payload inspection, with an env-flag-first pattern: install one library, wire one middleware, keep it off until the operator flips the flag. It can list several options side by side — slowapi, fastapi-limiter, fastapi-guard — with honest one-liners about scope (slowapi: rate limiting only; fastapi-guard: rate limits + WAF patterns + per-route policies). This adds zero dependencies and zero code, matches the template's educational mission, and answers the #307 question permanently.
Option 2 — optional stub. A commented-out or settings-gated middleware block in main.py plus a docs section, disabled by default. I know non-team PRs can't touch pyproject.toml/uv.lock, so this would ship as an optional extra documented in the README — the dependency only installs if the deployer asks for it.
Option 1 is the one I'd start with; it's a pure docs change and doesn't need the dependency discussion at all.
What this is not
No intent to change the default template behavior: whatever lands stays off by default, adds no required dependency, and leaves auth/CORS exactly as they are. Also worth saying plainly: none of these libraries (mine included) address DDoS or auth bypass — that's edge/proxy territory.
Offer
Happy to send a PR for the docs section (Option 1) — written to list all the libraries fairly — if maintainers want it.
about: Add application-layer security (rate limiting, request inspection) as documented hardening
title: "Docs: hardening-for-production section (rate limiting + payload inspection) and optional opt-in middleware"
labels: documentation
Disclosure first: I maintain fastapi-guard, a FastAPI security middleware, so I have an affiliation here — please judge the suggestion on its merits. I'm deliberately proposing a docs-first option that treats every library (including mine) equally.
What I found
This template is the starting point for a huge number of production FastAPI deployments, and it does auth, DB migrations and Docker orchestration well. On the application-layer request-security side it currently ships only
CORSMiddleware(backend/app/main.py:27-28), and the README doesn't mention rate limiting or request inspection anywhere. #307 ("How to use api rate limit") was answered with "follow the slowapi docs" — which is the right per-question answer, but it means every deployer rediscovers the same wire-up by hand.What's missing isn't auth (the template has JWT with refresh, that's solid) — it's the perimeter questions the template currently doesn't address:
/login(credential stuffing),/signup, or any API route; nothing per-IP or per-user./.env,/wp-login.php, ...).These are the gaps every template consumer eventually fills themselves — or doesn't.
Proposal (two options, both opt-in and default-off)
Option 1 — docs only (my ask). A short "Hardening for production" section in the README or
development.mdcovering rate limiting + payload inspection, with an env-flag-first pattern: install one library, wire one middleware, keep it off until the operator flips the flag. It can list several options side by side — slowapi, fastapi-limiter, fastapi-guard — with honest one-liners about scope (slowapi: rate limiting only; fastapi-guard: rate limits + WAF patterns + per-route policies). This adds zero dependencies and zero code, matches the template's educational mission, and answers the #307 question permanently.Option 2 — optional stub. A commented-out or settings-gated middleware block in
main.pyplus adocssection, disabled by default. I know non-team PRs can't touchpyproject.toml/uv.lock, so this would ship as an optional extra documented in the README — the dependency only installs if the deployer asks for it.Option 1 is the one I'd start with; it's a pure docs change and doesn't need the dependency discussion at all.
What this is not
No intent to change the default template behavior: whatever lands stays off by default, adds no required dependency, and leaves auth/CORS exactly as they are. Also worth saying plainly: none of these libraries (mine included) address DDoS or auth bypass — that's edge/proxy territory.
Offer
Happy to send a PR for the docs section (Option 1) — written to list all the libraries fairly — if maintainers want it.