Brute Force Attack in Fastapi

In Fastapi, brute force attacks typically target authentication endpoints such as login routes or token validation paths. Attackers use automated scripts to submit many username and password combinations or token values, aiming to discover valid credentials or cause account lockouts. Common patterns include credential stuffing against /login and iterative guessing against password reset or OTP verification routes. Because Fastapi often exposes JSON-based APIs, attackers can send high-volume POST requests with JSON payloads, leveraging Fastapi’s automatic request body parsing to avoid basic validation hurdles.

Fastapi-specific code paths where brute force risk appears include endpoints that use OAuth2PasswordRequestForm or manually parsed JSON bodies without additional protections. For example, an endpoint that authenticates by checking a username and password against a database can become an abuse surface when there is no limit on attempts per identity or per IP. Similarly, routes that verify time-based one-time passwords (TOTP) or API keys can be targeted if they do not enforce rate limits or lockout policies. Because Fastapi relies on dependency injection for security utilities, missing or misconfigured dependencies (such as a per-user rate limiter) can unintentionally allow unchecked rapid requests.

Attackers may also probe token introspection or password reset endpoints using valid-looking but forged requests. If Fastapi routes do not throttle requests or enforce cooldown periods, iterative guessing can proceed rapidly. In multi-tenant or role-based systems, attackers may iterate over usernames within a tenant to enumerate valid accounts, which can then be used for more targeted attacks. Because Fastapi applications often serve as upstream services behind an API gateway, the absence of application-layer protections can shift the burden to less effective perimeter controls.

Detecting brute force risks in Fastapi requires correlating runtime behavior with configuration and code patterns. Scanning with middleBrick exposes authentication and rate-limiting weaknesses by observing how the API responds to repeated requests without triggering mitigations. middleBrick’s 12 security checks run in parallel and include Authentication, Rate Limiting, and Input Validation, which collectively assess whether endpoints allow unchecked rapid attempts. The scanner cross-references OpenAPI/Swagger specifications (including $ref resolution) with observed runtime behavior to identify discrepancies such as undocumented login routes or missing security schemes.

During a scan, middleBrick tests unauthenticated attack surfaces, which is effective for identifying endpoints that lack required authentication or that permit excessive attempts. For Fastapi-based APIs, middleBrick can detect whether rate-limiting mechanisms are applied at the route level and whether they vary by user or IP. It also checks whether authentication endpoints inadvertently disclose information that can aid enumeration, which often precedes brute force campaigns. By analyzing both the spec and runtime responses, middleBrick highlights missing protections such as missing dependency guards or misconfigured security utilities.

Using the CLI, you can run middlebrick scan <url> to initiate a scan against a Fastapi service. The resulting report provides per-category breakdowns and prioritized findings with severity and remediation guidance. For example, a finding might indicate that a /login endpoint does not enforce attempt limits and recommends implementing rate limiting. The Web Dashboard allows you to track these findings over time, while the GitHub Action can fail builds if security scores drop below a chosen threshold, ensuring that new routes are evaluated before deployment.

Remediation for brute force attacks in Fastapi centers on reducing the attack surface for credential guessing and enforcing attempt limits. Use Fastapi’s dependency injection to centralize authentication logic and apply rate limiting per user or per IP. Libraries such as fastapi-ratelimit or integrating with Redis-backed solutions can enforce cooldowns and blocklists. For example, a login route can validate credentials while incrementing a counter keyed by username or IP, returning HTTP 429 when a threshold is exceeded.

Code examples using Fastapi’s native features demonstrate how to implement these protections. Below is a login endpoint that uses a simple in-memory attempt tracker along with Fastapi dependencies to enforce per-username rate limits. In production, replace the in-memory store with a distributed cache to ensure consistency across workers and instances.

from fastapi import Fastapi, Depends, HTTPException, status
from fastapi.security import OAuth2PasswordRequestForm
from typing import Dict
import time

app = Fastapi()

# Simple in-memory rate limit store: {username: [attempt timestamps]}
attempts: Dict[str, list] = {}

def is_rate_limited(username: str, max_attempts: int = 5, window_seconds: int = 60) -> bool:
    now = time.time()
    attempts.setdefault(username, [])
    # Remove old attempts
    attempts[username] = [t for t in attempts[username] if now - t < window_seconds]
    if len(attempts[username]) >= max_attempts:
        return True
    attempts[username].append(now)
    return False

@app.post("/login")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    username = form_data.username
    if is_rate_limited(username):
        raise HTTPException(
            status_code=status.HTTP_429_TOO_MANY_REQUESTS,
            detail="Too many login attempts. Try again later.",
        )
    # Replace with actual credential verification
    if username != "admin" or form_data.password != "securepassword":
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Incorrect username or password",
            headers={"WWW-Authenticate": "Bearer"},
        )
    return {"access_token": username, "token_type": "bearer"}

For broader protection, apply global rate limiting to authentication-related paths using middleware or Fastapi dependencies. Combine this with account lockout policies after sustained suspicious activity and ensure that responses do not reveal whether a username exists to prevent user enumeration. When using token-based flows, enforce rate limits on token validation and refresh endpoints as well.

In larger deployments, integrate Fastapi with centralized monitoring and anomaly detection to identify bursts of failed attempts that indicate active brute force campaigns. The Pro plan’s continuous monitoring can help detect such patterns across multiple APIs, while the GitHub Action can enforce risk thresholds in CI/CD pipelines to prevent new routes from being deployed without adequate protections.