Password Spraying in Django with Firestore

Password spraying is an authentication attack where a single password is attempted against many accounts to avoid account lockouts. In a Django application using Google Cloud Firestore as the user store, several implementation patterns can unintentionally enable or amplify this risk.

When user existence is confirmed before password verification, or when rate-limiting is enforced at the Django layer only, attackers can enumerate valid usernames while evading temporary lockouts. Firestore’s server-side nature and eventual consistency do not prevent application logic from leaking timing differences or existence signals.

Consider a login view that queries Firestore to check if a username exists before validating the password:

from google.cloud import firestore
from django.http import JsonResponse

def login_view(request):
    username = request.POST.get('username')
    password = request.POST.get('password')
    db = firestore.Client()
    user_ref = db.collection('users').document(username)
    doc = user_ref.get()
    if not doc.exists:
        return JsonResponse({'error': 'Invalid credentials'}, status=401)
    # password verification omitted for brevity
    return JsonResponse({'ok': True})

In this pattern, an attacker can enumerate valid usernames by observing HTTP status codes or response timing, even if the final password check is slow. Because Firestore reads are separate from Django session handling, there is no built-in account lockout at the service level; any mitigation must be implemented in application code.

The authentication check in the example leaks user existence via two channels: the presence of a document and the timing of the read. An attacker conducting a password spray can iterate through common usernames (e.g., admin, test, user) and reliably identify which usernames exist without triggering per-account lockouts.

Additionally, if Django’s session or token generation is tied to Firestore document reads without constant-time comparison, subtle timing differences may allow adaptive attackers to refine their spray list. Firestore indexes do not protect against enumeration when the document ID maps directly to the username.

Compliance mappings such as OWASP API Top 10 (2023) A07:2021 – Identification and Authentication Failures apply here. PCI-DSS and SOC2 also expect controls against credential stuffing and enumeration. middleBrick’s Authentication and BOLA/IDOR checks can surface these risks by correlating endpoint behavior with the exposed attack surface.

To mitigate password spraying when Django uses Firestore, ensure that authentication paths do not reveal user existence and enforce rate-limiting and constant-time checks at the application layer.

1. Use a constant-time existence check and a fixed-duration password verification step regardless of user existence:

import time
import hashlib
from google.cloud import firestore
from django.http import JsonResponse

def dummy_hash():  # Simulate work to prevent timing leaks
    return hashlib.sha256(b'x' * 10000).hexdigest()

def verify_password(stored_hash, password):
    # Simulate constant-time work; in practice use a proper KDF like argon2 or PBKDF2
    dummy_hash()
    return stored_hash == hashlib.sha256(password.encode()).hexdigest()

def login_view(request):
    username = request.POST.get('username')
    password = request.POST.get('password')
    db = firestore.Client()
    user_ref = db.collection('users').document(username)
    doc = user_ref.get()
    stored_hash = doc.to_dict().get('password_hash') if doc.exists else dummy_hash()
    # Always run verification to prevent timing leaks
    verify_password(stored_hash, password)
    # Return a generic response
    return JsonResponse({'error': 'Invalid credentials'}, status=401)

This pattern ensures that response time and status codes do not reveal whether the username exists. The dummy hash provides a consistent baseline cost for missing users.

2. Implement rate-limiting and monitoring at the endpoint level to limit attempts per identity or IP. While Firestore does not provide native lockout, Django middleware or a lightweight cache (e.g., Redis) can enforce request throttling:

# Example using Django cache-based rate limiting
from django.core.cache import cache
from django.http import JsonResponse
from datetime import timedelta

def login_view_with_ratelimit(request):
    username = request.POST.get('username')
    key = f'login_attempt:{username}'
    attempts = cache.get(key, 0)
    if attempts >= 10:
        return JsonResponse({'error': 'Too many attempts'}, status=429)
    # ... authentication logic from previous example ...
    cache.set(key, attempts + 1, timeout=timedelta(minutes=15))
    return JsonResponse({'ok': True})

3. If using middleBrick, run the CLI scan to validate that your endpoints do not expose user enumeration:

middlebrick scan https://api.example.com/login

Findings from the Authentication and BOLA/IDOR checks can highlight inconsistent timing behavior or missing rate controls. The Dashboard can track changes over time, and the GitHub Action can gate merges if the score falls below your chosen threshold.