You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Production hardening: template ships CORS only — no rate limiting or request inspection (docs-first proposal) #2486
Disclosure: I maintain fastapi-guard (FastAPI security middleware), so this suggestion comes with an affiliation — judge it on merits.
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"). Since this template is the starting point for a lot of production FastAPI apps, the default posture of "thousands of deployments" is: no per-client ceilings, no protection against scripted abuse or injection attempts.
I fully respect that the template's scope philosophy is minimal and that rate limiting is deployment-specific (ingress, CDN, or app-layer — reasonable people choose differently). That's exactly why this is a docs-first proposal:
Proposal
Option 1 — docs-only (my preference). A short "Hardening for production" section in the README or development.md: what the template does NOT cover (rate limiting, request inspection, bot/probe filtering), and how to plug each in at app layer — e.g. slowapi or fastapi-limiter for per-route limits, or fastapi-guard for the broader pipeline (it ships a passive/log-only mode so you can preview what would be blocked before enforcing anything). One paragraph on where the edge (reverse proxy/CDN) belongs in the picture would prevent the most common misconfiguration.
Option 2 — optional middleware stub behind a settings flag (default off), showing the wiring without adding a default dependency. Keeps the template dependency-light; costs a little maintenance.
Happy to PR either one. If it's Option 1, the only ask is guidance on where you'd want the section to live (README vs docs), so the PR lands right the first time.
Moving this to discussion #2488 per the repo's contribution flow (PRs only after a maintainer asks, discussions first). The PR #2487 was likewise withdrawn — everything is consolidated in that one thread.
Activity
rennf93 commentedon Sep 24, 2026
Moving this to discussion #2488 per the repo's contribution flow (PRs only after a maintainer asks, discussions first). The PR #2487 was likewise withdrawn — everything is consolidated in that one thread.