Broken Authentication in Actix with Firestore

Broken Authentication occurs when identity verification and session management functions are implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens. In an Actix web service that uses Google Firestore as the identity store, the risk is amplified by common misconfigurations and insecure patterns in handling user credentials and tokens.

Actix is a high-performance Rust framework for building asynchronous web services. When combined with Firestore — a NoSQL document database often used for user profiles and session data — the application must correctly validate credentials, manage sessions, and enforce access controls on every request. Missteps in any of these steps can lead to authentication bypass, credential leakage, or account takeover.

One common pattern is storing user documents in a users collection keyed by user ID or email. If Firestore security rules are not strict — for example, allowing read or write access based only on request origin or without validating the authenticated subject — an attacker can manipulate requests to access or modify other users’ documents. In Actix, if the handler retrieves a user ID from a token but does not re-verify permissions against Firestore on each operation, the system may rely on the client-supplied identifier, enabling Insecure Direct Object Reference (IDOR) and privilege escalation.

Another vulnerability vector is weak session management. If Actix stores session identifiers in cookies without the HttpOnly, Secure, and SameSite attributes, or uses predictable session tokens, attackers can steal or guess session identifiers. Firestore may store session documents with a Time-To-Live (TTL), but if the session cleanup or token validation logic in Actix does not properly validate the session against the database, an attacker can reuse an expired or revoked token.

Additionally, Firestore rules must enforce ownership explicitly. A rule such as allowing a user to read only documents where userId == request.auth.uid is essential. If the Actix backend does not re-validate this ownership — for example, by using a user ID from a decoded JWT to construct a document path without server-side verification — the API may expose data across users. This is a classic BOLA/IDOR issue that manifests severely when Firestore rules are misconfigured or bypassed by trusting client input.

Finally, transmitting credentials or tokens without encryption in transit, or logging sensitive authentication data in Actix middleware, can expose information to interception or leakage. Firestore already enforces TLS, but the application must ensure that authentication requests and responses are handled over HTTPS and that tokens are not logged or exposed in error messages returned by Actix handlers.

To secure authentication in an Actix service using Firestore, implement strict server-side validation, least-privilege rules, and safe token handling. Below are concrete code examples and configuration guidance.

Firestore security rules (Firebase console)

Define rules that enforce ownership and scope access to the minimal required operations:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    match /sessions/{sessionId} {
      allow read, write: if request.auth != null && request.auth.uid == request.resource.data.userId;
    }
  }
}

This ensures that only authenticated users can access their own documents and that session writes include a matching userId field.

Actix handler with Firestore validation

In your Actix route, decode the token server-side, then use the authenticated UID to construct document references and re-validate against Firestore. Do not trust path parameters or client-supplied IDs.

use actix_web::{web, HttpResponse, Result};
use google_cloud_rust::firestore::client::FirestoreClient;
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};

async fn get_user_profile(
    token: String,
    firestore_client: web::Data<FirestoreClient>,
) -> Result<HttpResponse> {
    // Decode token using server-side secret
    let validation = Validation::new(Algorithm::HS256);
    let token_data = decode::decode(&token, &DecodingKey::from_secret("YOUR_SECRET".as_ref()), &validation)
        .map_err(|_| HttpResponse::Unauthorized().finish())?;

    let uid = token_data.claims.sub; // subject claim as user ID
    let users_ref = firestore_client.collection("users").doc(uid.clone());
    let user_doc = users_ref.get().await.map_err(|_| HttpResponse::InternalServerError().finish())?;

    if user_doc.exists() {
        let user_data: serde_json::Value = user_doc.data().ok_or_else(|| HttpResponse::BadRequest().finish())?;
        Ok(HttpResponse::Ok().json(user_data))
    } else {
        Ok(HttpResponse::NotFound().finish())
    }
}

Key points: the handler decodes the JWT using a server-side secret, extracts the subject as the UID, and uses that UID to fetch the Firestore document. It does not accept a user ID from the URL or from the token payload beyond the subject claim.

Secure session handling

When creating sessions, store minimal data server-side and set secure cookies:

use actix_web::{cookie, HttpResponse};

fn create_session_response(user_id: String) -> HttpResponse {
    let session_id = generate_secure_random_id();
    // Store session in Firestore with userId and expiry
    // ... write to Firestore sessions collection ...

    HttpResponse::Ok()
        .cookie(
            cookie::Cookie::build(("session_id", session_id))
                .http_only(true)
                .secure(true)
                .same_site(cookie::SameSite::Lax)
                .path("/")
                .finish(),
        )
        .finish()
}

Ensure cookies are HttpOnly to prevent JavaScript access, Secure to enforce HTTPS, and SameSite to mitigate CSRF. Rotate session IDs on privilege changes and validate them server-side against Firestore on each request.

Rate limiting and monitoring

Apply rate limiting at the Actix middleware layer to mitigate credential stuffing and brute-force attacks. Combine with Firestore usage monitoring and alerts for anomalous authentication patterns.

By combining strict Firestore rules, server-side token validation in Actix, secure cookie attributes, and continuous monitoring, you reduce the attack surface for broken authentication and prevent common identity-related vulnerabilities.