Broken Authentication in Axum with Firestore

Broken Authentication in an Axum service backed by Firestore typically arises when session or token handling is implemented on top of Firestore user documents without enforcing strict access boundaries and secure storage practices. Axum is a Rust web framework that does not prescribe a specific authentication mechanism, which means developers must explicitly design identity verification, session validation, and credential storage. Firestore, as a hosted NoSQL database, provides strong server-side security rules, but those rules are only as effective as the surrounding application logic.

One common pattern is storing user credentials or session tokens directly in Firestore collections. If Firestore security rules do not enforce ownership and least-privilege access, one user may read or modify another user’s document, leading to Insecure Direct Object References (IDOR) or Broken Object Level Authorization (BOLA). For example, a rule that allows allow read, write: if request.auth != null; without scoping to the user’s own document enables horizontal privilege escalation across authenticated users.

Another risk specific to the Axum + Firestore combination is the misuse of service account credentials in server-side handlers. Axum application code that initializes a Firestore client using a highly privileged service account and then performs lookups or mutations based solely on user-supplied identifiers can inadvertently expose data or enable impersonation. If the application conflates authentication (proving identity) with authorization (verifying permissions), a malicious actor who obtains a valid user ID might directly query Firestore for other users’ records.

Session management in Axum often relies on cookies or bearer tokens. If tokens or session identifiers stored in Firestore are not properly scoped, rotated, or invalidated, an attacker who steals a token can maintain access indefinitely. Additionally, weak password storage in Firestore (e.g., missing proper hashing or using reversible encryption) means a compromised Firestore read leads directly to credential compromise. The absence of rate limiting on authentication endpoints in Axum can also enable online credential stuffing or brute-force attacks against Firestore-backed user directories.

Compliance mappings such as OWASP API Top 10 (2023) A07:2021 — Identification and Authentication Failures highlight these risks. Firestore rules should explicitly enforce that users can only access their own documents using request.auth.uid == document_id patterns, and Axum handlers must validate and scope every Firestore query to the authenticated subject rather than trusting path parameters alone.

Remediation centers on strict separation of authentication and authorization, scoped Firestore rules, and safe handling of credentials and tokens in Axum handlers. Below are concrete patterns and code examples for Rust Axum applications using the Firestore emulator or production Firestore.

1. Firestore security rules (Firestore Native mode)

Scope reads and writes to the authenticated user’s own document. Avoid broad allow rules.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    // Other collections should follow similar ownership scoping
  }
}

2. Axum handler: authenticate then authorize with scoped Firestore queries

Use a verified UID from the authentication layer to construct Firestore document references. Do not rely on client-supplied identifiers for document paths.

use axum::{
    extract::{State, TypedExtension},
    http::StatusCode,
    response::IntoResponse,
    Json,
};
use firestore_rs::{FirestoreDb, FirestoreError};
use serde::{Deserialize, Serialize};

#[derive(Deserialize, Serialize)]
struct UserProfile {
    uid: String,
    email: String,
    // other fields, avoid storing secrets here
}

async fn get_profile(
    State(db): State<FirestoreDb>,
    TypedExtension(uid): TypedExtension<String>, // authenticated UID from your auth extractor
) -> Result<impl IntoResponse, (StatusCode, String)> {
    // Scope explicitly to the authenticated user's document
    let doc_ref = db.doc(&format!("users/{}", uid));
    let profile: UserProfile = doc_ref
        .get()
        .await
        .map_err(|e: FirestoreError| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?
        .ok_or((StatusCode::NOT_FOUND, "Profile not found".to_string()))?;
    Ok(Json(profile))
}

3. Secure password handling and user creation

Hash passwords before storing them in Firestore. Use a strong adaptive hashing algorithm such as Argon2id. Do not store plaintext or reversibly encoded passwords.

use argon2::{self, Config};

fn hash_password(plain: &str) -> Result<String, argon2::Error> {
    let config = Config::default();
    argon2::hash_encoded(plain.as_bytes(), b"somesalt", &config)
}

fn verify_password(plain: &str, encoded: &str) -> bool {
    argon2::verify_encoded(encoded, plain.as_bytes()).unwrap_or(false)
}

When creating a user document, ensure the UID used as the document ID matches the authenticated identity and that rules prevent creation by arbitrary IDs.

4. Token/session handling

If using JWTs, keep tokens short-lived and store refresh token metadata (revocation state, user binding) in Firestore with strict ownership rules. Invalidate sessions server-side by updating a revocation flag in the user’s own document and validate this flag on each request.

5. Avoid privilege escalation via service accounts

Configure Firestore clients with the minimal required permissions. In server-side Axum handlers, do not perform wide reads or use elevated service accounts to fetch user data; instead, scope reads to the user’s document using the authenticated UID. This aligns with the principle of least privilege and reduces the impact of compromised credentials.

By combining scoped Firestore rules, precise UID-based document references in Axum handlers, strong password hashing, and disciplined session invalidation, the risk of Broken Authentication in this stack is substantially reduced while preserving the flexibility of Rust and the scalability of Firestore.