Credential Stuffing in Actix with Firestore

Credential stuffing is a brute-force technique where attackers use lists of known username and password pairs to gain unauthorized access. When an Actix web service uses Google Cloud Firestore as its user store without additional protections, the architecture can inadvertently support or amplify this attack vector. The risk stems from how Actix handles authentication requests and how Firestore stores and indexes credentials data.

In an Actix application, login endpoints typically parse a JSON payload containing email and password, then query Firestore to locate the matching user document. If the endpoint does not enforce strict rate limiting or captcha challenges, an attacker can automate thousands of requests per minute using credential stuffing tools. Because Firestore queries are indexed and fast, an attacker can iterate through email addresses quickly, and the absence of account lockout mechanisms means each request returns a definitive response: either a valid user exists (with a correct password) or the user does not exist or the password is incorrect.

Another contributing factor is the exposure of user enumeration via timing differences or response messages. If the Actix handler returns different HTTP status codes or response bodies for "user not found" versus "incorrect password," an attacker can infer valid accounts. Firestore’s consistent read latency for existing documents can further aid an attacker in distinguishing real users when response times differ subtly. Without middleware that normalizes responses and enforces global rate limits across all authentication attempts, the service becomes susceptible to large-scale credential testing.

Additionally, if the Firestore security rules are misconfigured—permissive read or write access based on request authentication state—an attacker might leverage stolen credentials to access or modify other users’ data. This expands the impact of credential stuffing beyond mere authentication bypass to potential horizontal or vertical privilege escalation. The combination of a straightforward REST API in Actix and a highly accessible Firestore database creates an environment where automated login attempts can be executed at scale with minimal friction.

Securing an Actix service that relies on Firestore requires both application-level controls and careful structuring of Firestore rules. The following code examples illustrate concrete remediation steps, including rate-aware login handling and secure Firestore access patterns.

First, implement a login endpoint in Actix that avoids leaking account existence through consistent response times and status codes. Use a fixed-duration dummy hash when the user is not found to prevent timing attacks.

use actix_web::{post, web, HttpResponse, Responder};
use firestore::*;
use serde::{Deserialize, Serialize};

#[derive(Deserialize)]
struct LoginPayload {
    email: String,
    password: String,
}

#[derive(Serialize)]
struct LoginResponse {
    success: bool,
    message: String,
}

// Dummy hasher to prevent timing leaks
async fn dummy_hash() {
    use argon2::Config;
    let config = Config::default();
    let _ = argon2::hash_encoded(b"dummy", b"dummy_salt", &config).unwrap();
}

#[post("/login")]
async fn login(
    payload: web::Json,
    db: web::Data,
) -> impl Responder {
    // Always perform the lookup to keep timing consistent
    let user_ref = db.collection("users").doc(&payload.email);
    let maybe_user: Option = match user_ref.get().await {
        Ok(user) => Some(user),
        Err(_) => None,
    };

    // Perform dummy work regardless of user existence
    dummy_hash().await;

    // Compare only if user exists
    if let Some(user) = maybe_user {
        if verify_password(&payload.password, &user.password_hash).await {
            return HttpResponse::Ok().json(LoginResponse {
                success: true,
                message: "Login successful".into(),
            });
        }
    }

    HttpResponse::Unauthorized().json(LoginResponse {
        success: false,
        message: "Invalid credentials".into(),
    })
}

async fn verify_password(password: &str, hash: &str) -> bool {
    argon2::verify_encoded(hash, password.as_bytes()).unwrap_or(false)
}

struct UserDocument {
    password_hash: String,
}

// Firestore deserialization helper
impl firestore::FirestoreDeserialize for UserDocument {
    fn firestore_deserialize(value: &firestore::FirestoreValue) -> Result {
        let map = value.as_map()?;
        let password_hash = map.get("password_hash")
            .and_then(|v| v.as_str())
            .map(String::from)
            .ok_or_else(|| firestore::FirestoreError::DeserializationError("missing password_hash".into()))?;
        Ok(UserDocument { password_hash })
    }
}

Second, enforce strict Firestore security rules to ensure that even if credentials are compromised, lateral movement is restricted. Rules should scope reads and writes to a user’s own document and deny broad access.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
      // Explicit deny for unauthenticated attempts
      allow read, write: if false;
    }
  }
}

Third, add middleware in Actix to enforce rate limiting on authentication endpoints. This reduces the feasibility of high-volume credential stuffing. Use a sliding window counter stored in a fast in-memory or external store, checked before processing each login request.

use actix_web::dev::{ServiceRequest, ServiceResponse};
use actix_web::Error;
use std::time::Duration;

async fn rate_limit_middleware(
    req: ServiceRequest,
    limit: usize,
    window: Duration,
) -> Result {
    // Implementation would track IP or user identifier and reject excess requests
    // Placeholder: proceed if under limit
    Ok(req.into_response(req.service_response().map(|r| r.into_body())))
}
// In your Actix app configuration:
// App::new()
//     .wrap_fn(|req, srv| rate_limit_middleware(req, 5, Duration::from_secs(60)))
//     .service(login)

Finally, enforce HTTPS and require strong password policies to mitigate credential reuse and interception risks. Combine these measures with monitoring for anomalous login patterns, such as many failed attempts from a single IP or geographic region, to detect active attacks early.