Dictionary Attack in Actix with Firestore

A dictionary attack against an Actix web service that relies on Firestore as the identity backend can be effective when authentication endpoints do not enforce adequate rate limiting or account lockout. In this scenario, an attacker submits many common passwords or leaked credential lists against a login route that queries Firestore to validate a username and password pair. Because Firestore reads are billable operations and typically do not introduce artificial delays, an attacker can perform a high-volume brute-force campaign without triggering expensive resource consumption on the database itself.

The risk is compounded when the Actix handler reveals whether a username exists. If the handler returns different HTTP statuses or timing behavior for valid versus invalid users, the attacker gains user enumeration, which narrows the dictionary to likely candidates. Each request performs a Firestore document read (e.g., fetching a user document by email), and without server-side protections the attacker can sustain thousands of attempts per minute. The absence of per-identifier rate limiting means that even if the overall API has generic throttling, a targeted account can be hammered independently.

Because middleBrick scans the unauthenticated attack surface, it can detect whether authentication endpoints are vulnerable to enumeration and whether rate limiting is applied at the identifier level. One of the 12 parallel checks, BOLA/IDOR, examines whether authenticated contexts properly scope access; a related check for Rate Limiting evaluates whether limits are strict enough to impede rapid guessing. In a dictionary attack, the attacker does not need stolen credentials—only a list of common passwords and a reachable endpoint that leaks information through timing or status codes.

An example of a vulnerable Actix login handler is one that directly maps a JSON body field to a Firestore document ID or field without additional validation. If the attacker automates requests with slight variations in username or password, they can iterate through accounts and passwords efficiently. The handler may return 200 with an error body for bad passwords and 302 or 200 with a session token for good credentials, giving away the validity of usernames and enabling adaptive dictionary strategies.

middleBrick’s LLM/AI Security checks are not relevant to this purely credential-guessing vector, but the scanner’s Authentication and Rate Limiting checks surface the absence of defenses. Findings include severity ratings and remediation guidance, emphasizing the need for constant-time comparison, account lockout or exponential backoff, and per-user rate limits that cannot be bypassed by simply creating new identities.

To mitigate dictionary attacks in an Actix service backed by Firestore, implement server-side rate limiting that is keyed by both user identifier and IP address, and ensure login responses do not reveal whether a username exists. Use constant-time operations for password verification and avoid branching logic that changes response timing based on record existence.

Below is a concrete example of a hardened login handler in Actix with Firestore integration. It uses a fixed delay to obscure timing differences and returns a generic response regardless of username validity. It also demonstrates how to structure Firestore reads safely without exposing document existence through behavior changes.

use actix_web::{post, web, HttpResponse, Result};
use firebase_admin_rs::Firestore; // hypothetical Firestore SDK for illustration
use serde::{Deserialize, Serialize};
use std::time::Duration;
use tokio::time::sleep;

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

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

/// Constant-time string comparison to avoid timing leaks.
fn constant_time_eq(a: &str, b: &str) -> bool {
    use subtle::ConstantTimeEq;
    let a_ct = subtle::ConstantTime::new(a.as_bytes());
    let b_ct = subtle::ConstantTime::new(b.as_bytes());
    a_ct.ct_eq(&b_ct).into()
}

#[post("/login")]
async fn login(
    body: web::Json,
    firestore: web::Data,
) -> Result {
    let email = body.email.trim().to_lowercase();
    // Always fetch a document; do not early-exit on missing user.
    let user_doc = firestore
        .collection("users")
        .doc(&email)
        .get()
        .await;

    // Simulate work to obscure timing even when user is not found.
    sleep(Duration::from_millis(300)).await;

    let stored_hash = match user_doc {
        Ok(doc) => doc.get::("password_hash").unwrap_or_default(),
        Err(_) => String::from("$2b$04$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"), // dummy hash
    };

    // Constant-time comparison regardless of user existence.
    let is_valid = constant_time_eq(&body.password, &stored_hash);

    // Generic response; do not indicate whether username exists.
    let response = if is_valid {
        // In real systems, issue a session token here.
        LoginResponse {
            success: true,
            message: String::from("Authentication succeeded"),
        }
    } else {
        LoginResponse {
            success: false,
            message: String::from("Invalid credentials"),
        }
    };

    Ok(HttpResponse::Ok().json(response))
}

On the infrastructure side, configure per-user rate limits in your API gateway or Actix middleware so that a single identifier cannot exceed a low threshold within a minute. Combine this with IP-based throttling to reduce collateral abuse while preserving availability for legitimate users. Ensure that error messages remain consistent and that Firestore read patterns do not inadvertently signal record existence through latency or status code differences.

middleBrick’s dashboard can help you track changes over time, and the CLI allows you to integrate scans into scripts. For teams that require stronger guarantees, the Pro plan adds continuous monitoring and can integrate with CI/CD pipelines to fail builds if security scores degrade. These features support ongoing hardening but do not replace secure coding practices like constant-time checks and thoughtful rate limiting.