Docs: hardening-for-production section (rate limiting + payload inspection) — proposal

[rennf93]

Disclosure: I maintain fastapi-guard (FastAPI security middleware), so the affiliation is stated up front — judge the proposal on its merits. All libraries are listed equally below, and per tiangolo's contributing guide this starts here as a discussion rather than as a PR (the premature PR #2487 is withdrawn).

What the template ships today

backend/app/main.py adds exactly one middleware: CORSMiddleware. There is no rate limiting and no request-level payload inspection anywhere in the template, and the README — genuinely strong on auth, DB, and Docker — never mentions either (zero matches for "rate limit"). This template is the default starting point for production FastAPI apps, which makes its default posture the default posture of thousands of deployments: no per-client ceilings on /login or /signup, nothing against scripted abuse or injection shapes, and every deployer rediscovers the wire-up by hand (#307 was answered with "follow the slowapi docs" — right per-question, but it repeats forever).

What's missing isn't auth (the template's JWT with refresh is solid) — it's the perimeter layer.

Proposal: a short "Hardening for production" docs section

A pure docs change (README or development.md), zero dependencies, zero code:

• What the template deliberately does NOT cover: rate limiting, request inspection, bot/probe filtering.
• How to plug each in at the app layer, options side by side with honest one-liners about scope — e.g. slowapi (rate limiting only), fastapi-limiter (Redis-backed limits), fastapi-guard (rate limits + WAF patterns + per-route policies; passive/log-only mode to preview before enforcing).
• One paragraph drawing the layer boundary correctly: these middlewares own the application-layer flood problem (per-client ceilings, repeated-abuse bans, emergency lockdown) — that's the half the template currently leaves unanswered. Volumetric network floods are a different layer entirely (reverse proxy/CDN/edge), and the section should say so plainly instead of conflating the two.
• An env-flag-first pattern: keep the middleware off until the operator flips the flag.

If maintainers also want a settings-gated middleware stub in main.py (default off, optional dependency), I can draft that as a follow-up — but the docs section alone answers the #307 question permanently.

None of this changes default template behavior.

The ask

Is a docs section like this in scope for the template? If yes, my recommendation is development.md (the README covers deployment topology, and this is a development/runtime concern) — but I'll write it wherever maintainers prefer. Once a team member asks for the PR, I'll open it and link this discussion.