Distributed Denial Of Service in Fastapi with Api Keys

A DDoS risk in FastAPI when relying only on API keys arises because authentication happens after the request enters the application. If an endpoint accepts unauthenticated or lightly authenticated traffic before validating the key, an attacker can send many valid-looking requests that consume worker cycles, thread pool slots, or event-loop capacity. In a synchronous endpoint, each request ties up a worker; in an async endpoint with blocking calls, the event loop can be blocked by slow I/O or CPU-bound work. Even when API keys are validated, missing rate controls allow an attacker with a single key to open a low-cost, high-volume attack that degrades availability for all clients.

Consider a FastAPI route that uses an API key in a header but does not enforce rate limiting or request-cost accounting:

from fastapi import FastAPI, Depends, Header, HTTPException
app = FastAPI()

def get_key(x_api_key: str = Header(...)):
    if x_api_key != "my-secret-key":
        raise HTTPException(status_code=401, detail="Invalid API Key")
    return x_api_key

@app.get("/data")
async def read_data(key: str = Depends(get_key)):
    # No rate limiting; heavy processing or external call possible
    return {"key": key, "data": "sensitive"}

An attacker with the key can issue thousands of requests per second. If the operation involves I/O (e.g., a database or third-party HTTP call), connection pools or thread limits can be exhausted, causing legitimate requests to time out. Without per-key or overall rate limits, the API key mechanism provides authentication but not availability protection.

Middleware or framework-level protections are essential to ensure that authenticated endpoints remain reachable under load. Even when API keys rotate and are tightly scoped, DDoS can manifest through resource starvation if each authenticated request triggers expensive computation or unbounded concurrency.

Remediation combines authenticated routing with explicit rate limiting and lightweight request-cost controls. Use a dependency that validates the key early and enforce a token-bucket or fixed-window rate limit per key. This prevents a single compromised or malicious key from saturating workers.

Example with a header API key and rate limit using a simple in-memory counter (suitable for single-process prototypes; for distributed deployments use Redis or external token-bucket services):

from fastapi import FastAPI, Depends, Header, HTTPException, Request
from time import time
from collections import defaultdict

app = FastAPI()

# Simple in-memory rate limiter: 10 requests per 60 seconds per key
RATE_LIMIT = 10
WINDOW = 60
store = defaultdict(list)  # key -> list of timestamps

def validate_key(x_api_key: str = Header(...)):
    if x_api_key != "my-secret-key":
        raise HTTPException(status_code=401, detail="Invalid API Key")
    return x_api_key

def rate_limit(key: str = Depends(validate_key)):
    now = time()
    # purge old entries
    store[key] = [t for t in store[key] if now - t < WINDOW]
    if len(store[key]) >= RATE_LIMIT:
        raise HTTPException(status_code=429, detail="Rate limit exceeded")
    store[key].append(now)

@app.get("/data")
async def read_data(key: str = Depends(rate_limit)):
    # Keep work lightweight; offload heavy tasks to background jobs
    return {"key": key, "data": "sensitive"}

For production, prefer a robust solution such as an external rate limiter or API gateway that can enforce per-key quotas with low latency. Combine with concurrency limits on your ASGI server (e.g., limit worker processes/threads) and timeouts on downstream calls to reduce blast radius. In CI/CD you can add a middlewareware check to fail builds if critical routes lack rate controls; the middleBrick GitHub Action can integrate API security checks into your pipeline to catch missing protections before deployment.

Additionally, monitor per-key request volumes and error rates to detect abuse early. Rotate keys regularly and scope them to least privilege operations. These measures reduce the likelihood that a valid API key becomes a vector for Distributed Denial of Service, preserving availability while retaining the simplicity of API-key authentication.