Credential Stuffing in Fastapi with Firestore

Credential stuffing is an automated attack where attackers use lists of breached username and password pairs to gain unauthorized access to user accounts. When Fastapi is combined with Firestore, several design patterns common in serverless backends can unintentionally enable or amplify this risk. Firestore is often used as a user store with collections such as users or accounts, and endpoints that accept email and password fields are typical targets. If the Fastapi route performs a lookup by email and then validates credentials without protections like rate limiting or suspicious request detection, attackers can run large-scale automated logins using valid credentials sourced from other breaches.

The vulnerability surface increases when session or token handling is weak. For example, issuing long-lived tokens, failing to bind tokens to a device context, or not checking token reuse across IPs can allow attackers to reuse stolen credentials across sessions. Firestore security rules may inadvertently permit unauthenticated enumeration of user emails (e.g., via a public read rule on a user document path that includes the email), which enables attackers to verify which emails are registered before running credential stuffing campaigns. Additionally, predictable user identifiers (such as sequential numeric IDs or email-based document names) make automation easier for attackers. Without proper controls, Fastapi endpoints backed by Firestore can therefore become effective infrastructure for large-scale account compromise.

Another contributing factor is missing or weak Multi-Factor Authentication (MFA). Many Fastapi services rely solely on email/password authentication when Firestore stores user credentials or password hashes. If password hashes are improperly stored (e.g., using weak hashing algorithms or missing salts), stolen Firestore data can facilitate offline password cracking, further increasing account takeover risk. Even when hashing is strong, the absence of mechanisms like rate limiting per user or per IP, captchas, or suspicious login anomaly detection allows attackers to conduct high-throughput credential validation with minimal detection. Because Firestore rules are not designed to enforce complex rate controls, the burden falls on the Fastapi application layer to implement these protections.

To mitigate credential stuffing when using Fastapi with Firestore, implement layered defenses in both application code and Firestore security configuration. On the Fastapi side, enforce strict rate limiting on authentication endpoints, require MFA for sensitive actions, and avoid leaking account enumeration through consistent error messages and HTTP status codes. Firestore rules should be configured to prevent public enumeration of user data, and sensitive operations should require authenticated access with minimal privilege scopes.

Below are concrete Fastapi code examples that demonstrate secure handling of authentication against Firestore. These snippets assume you use the official Google Cloud Firestore client library and that Firestore is configured with strict rules that require authentication for user document writes and limited reads.

Rate-limited login endpoint with consistent responses

from fastapi import FastAPI, HTTPException, Depends, status
from fastapi.security import OAuth2PasswordRequestForm
from google.cloud import firestore
from datetime import timedelta
from slowapi import Limiter
from slowapi.util import get_remote_address
from slowapi.errors import RateLimitExceeded
import hashlib

app = FastAPI()
limiter = Limiter(key_func=get_remote_address)

def verify_password(plain_password: str, hashed_password: str) -> bool:
    # Use a strong KDF in production (e.g., argon2 or scrypt); this is illustrative
    return hashlib.sha256(plain_password.encode()).hexdigest() == hashed_password

def get_user_by_email(email: str):
    db = firestore.Client()
    users_ref = db.collection('users')
    query = users_ref.where('email', '==', email).limit(1)
    results = query.stream()
    for doc in results:
        return {"id": doc.id, **doc.to_dict()}
    return None

@app.post("/login")
@limiter.limit("5/minute")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    user = get_user_by_email(form_data.username)
    # Always perform hash check to prevent timing attacks
    if not user or not verify_password(form_data.password, user.get("password_hash", "")):
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Invalid credentials",
            headers={"WWW-Authenticate": "Bearer"},
        )
    # Issue token with appropriate scope and short expiration
    return {"access_token": "generated_token_here", "token_type": "bearer"}

Firestore security rules to prevent public enumeration

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
      // Prevent public listing or searching by email
      allow list: if false;
    }
    match /sessions/{sessionId} {
      allow create: if request.auth != null;
      allow read, update, delete: if request.auth.uid == request.resource.data.user_id;
    }
  }
}

Additional remediation steps include binding tokens to device fingerprints, implementing token rotation, and monitoring for anomalous login patterns (such as many failed attempts followed by success). The Fastapi layer should validate inputs rigorously, use prepared statements or parameterized queries where applicable, and ensure that Firestore queries are scoped to the minimum necessary index and document set. Combining these practices reduces the effectiveness of credential stuffing campaigns targeting Fastapi services backed by Firestore.