Credential Stuffing in Firestore

Credential stuffing attacks target authentication pathways that expose user credentials through Firestore-based services. In typical Firebase implementations, user sign‑in is handled by Firebase Authentication, which can be accessed via the REST endpoint /v1/projects/PROJECT_ID/users:signIn or through custom token generation in Cloud Functions. Attackers who have harvested username/password pairs from prior breaches will programmatically submit these credentials to the sign‑in endpoint, hoping that users reuse passwords across services.

Typical attack vectors include:

• Brute‑force POST requests to the Firebase Authentication REST API using common password lists.
• Automated enumeration of user IDs by attempting sign‑in with empty or generic passwords, then observing successful responses that reveal valid accounts.
• Exploitation of insecure Firestore security rules that allow unauthenticated reads of user collection documents, enabling attackers to harvest user identifiers for targeted credential stuffing.

These activities fall under OWASP API Top 10 category A07:2021 – Identification and Authentication Failures. A known vulnerability, CVE‑2022‑29193, demonstrated how an unauthenticated attacker could bypass Firebase Auth token validation in certain misconfigured Cloud Functions, enabling large‑scale credential stuffing.

Code that inadvertently opens this surface often looks like an open security rule:

service cloud.firestore {
  match /databases/{database}/documents {
    // Insecure rule – allows any request to read user documents
    match /users/{userId} { allow read: if true; }
  }
}

When combined with the sign‑in endpoint, attackers can script thousands of login attempts, each attempt potentially succeeding for a small fraction of reused credentials, leading to account takeover or password spray outcomes.

middleBrick detects credential stuffing by analyzing traffic to Firestore authentication endpoints and Firestore document reads that may expose user identifiers. During a scan, the tool performs one of the 12 parallel checks under the Authentication category, sending unauthenticated POST requests to the sign‑in endpoint with a list of common passwords. It monitors response patterns such as:

• Multiple 200‑OK responses in a short time frame.
• Increased count of invalid_credentials errors that suggests repeated attempts.
• Unusual spikes in traffic to the /users:signIn endpoint.

Example CLI usage:

middlebrick scan https://myapi.example.com/auth/v1/projects/my-project/auth:signIn?key=AIzaSy... --json

The JSON output includes a dedicated authentication section with a risk score, a list of failed credential attempts, and a recommendation to enable rate limiting or multi‑factor authentication. Because middleBrick operates as a black‑box scanner, no SDK keys or service accounts are required; the scan completes in 5–15 seconds and reports findings that map to OWASP categories.

Mitigating credential stuffing in Firestore requires layered controls that leverage Firebase Auth and Firestore security rules.

• Enable built‑in rate limiting: In the Firebase console, activate Rate limiting for sign‑in to throttle POST requests to the authentication endpoint. This reduces the feasibility of automated password spraying.
• Require strong password policies: Enforce minimum length and complexity through the Firebase Admin SDK when creating users programmatically.
• Apply strict Firestore security rules: Replace overly permissive rules with authenticated reads/writes. For example:

service cloud.firestore {
  match /databases/{database}/documents {
    // Only allow authenticated users to read/write their own profile
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Additionally, integrate reCAPTCHA or another challenge mechanism into custom sign‑in flows implemented with Cloud Functions. Example snippet that validates a reCAPTCHA token before proceeding with sign‑in:

exports.signInWithPassword = functions.https.onCall(async (data, context) => {
  const recaptchaToken = data.recaptchaToken;
  // Verify reCAPTCHA token with Google reCAPTCHA API
  const verificationUrl = `https://www.google.com/recaptcha/api/siteverify?secret=YOUR_SECRET&response=${recaptchaToken}`;
  const verificationResponse = await fetch(verificationUrl);
  const verification = JSON.parse(await verificationResponse.text());
  if (!verification.success) {
    throw new functions.https.HttpsError('failed_precondition', 'reCAPTCHA verification failed');
  }
  // Proceed with Firebase Auth sign‑in
  const {email, password} = data;
  return admin.auth().signInWithEmailAndPassword(email, password);
});

Finally, enable multi‑factor authentication (MFA) for privileged accounts and monitor anomalous sign‑in activity via Firebase Auth logs. These steps collectively raise the cost of credential stuffing attacks while preserving legitimate user access.