Padding Oracle in Actix with Firestore

A padding oracle in an Actix service that uses Firestore typically arises when user-supplied data influences both cryptographic operations and Firestore document lookups. For example, an API might accept an encrypted identifier, decrypt it to obtain a Firestore document key, and then query Firestore based on the result. If the application distinguishes between a decryption failure (bad padding) and a missing Firestore document, an attacker can learn whether a guessed ciphertext decrypts correctly by observing differences in HTTP responses or timing. This distinction creates an oracle that can be exploited to recover plaintext or forge valid tokens without access to the encryption key.

In this stack, the risk is compounded when the decrypted payload is used directly in a Firestore query such as doc_ref.path = decrypted_id. If the application returns a 404-style message for missing documents but a 400-style message for invalid padding, the observable behavior leaks information about the decryption result. An attacker can craft adaptive chosen-ciphertext requests, submitting modified ciphertexts and inspecting response codes or timing to infer the plaintext one block at a time. Because Firestore queries are remote and network latency is measurable, timing differences between a valid decryption+lookup and an invalid padding rejection can further amplify the oracle.

Actix routes that chain decryption and Firestore access are especially prone when error handling is inconsistent. For instance, if a middleware or handler converts a cryptographic exception into a generic 500 response but allows a Firestore not-found to surface as 404, the disparity provides a usable oracle. Even when the Firestore document exists, returning different JSON shapes or HTTP statuses depending on whether the decrypted ID matched a document can expose the padding validity. Common patterns include using JWTs encrypted with AES-CBC or RSAES-PKCS1-v1_5, where the padding is verified before any Firestore lookup, and the application logic inadvertently reflects the verification outcome through HTTP semantics.

Real-world attack patterns mirror the OWASP API Top 10:2023 category ‘Cryptographic Failures’ and map to behaviors similar to CVE-2021-34473 and CVE-2021-34527, where padding errors and timing leaks enabled token forgery. In an Actix + Firestore scenario, the remediation must address both the cryptographic handling and the Firestore interaction. This includes standardizing error responses, avoiding branching on decryption success before Firestore operations, and ensuring that any lookup does not reveal whether a document existence decision depended on a valid pad.

Compliance frameworks such as OWASP API Security Top 10 and PCI-DSS highlight the importance of treating cryptographic errors and data access uniformly. middleBrick scans can detect indicators of a potential padding oracle by correlating authentication checks, input validation, and data exposure findings across the unauthenticated attack surface, providing prioritized remediation guidance without claiming to fix the underlying logic.

Remediation focuses on making failure paths consistent and removing information leaks from Firestore interactions. Below are concrete Actix examples that avoid branching on padding validity before performing Firestore operations and that normalize responses regardless of decryption or lookup results.

Example 1: Consistent error handling with decryption and Firestore lookup

Ensure that decryption and Firestore lookup are attempted together within a uniform code path, returning a single error type for both cryptographic and missing document cases.

use actix_web::{web, HttpResponse, Result};
use firestore::FirestoreDb;
use openssl::symm::{decrypt, Cipher};

async fn get_secure_resource(
    path: web::Path,
    db: web::Data<FirestoreDb>,
) -> Result<HttpResponse> {
    let ciphertext = path.into_inner();
    let key = std::env::var("ENCRYPTION_KEY").expect("key missing");
    let cipher = Cipher::aes_256_cbc();
    let iv = &[0u8; 16]; // In practice, derive or pass IV safely

    // Attempt decryption; map all crypto errors to a generic failure
    let plaintext = match decrypt(cipher, key.as_bytes(), Some(iv), ciphertext.as_bytes()) {
        Ok(p) => p,
        Err(_) => {
            // Do NOT reveal whether this was padding or other crypto error
            return Ok(HttpResponse::unprocessable_entity().json(serde_json::json!({
                "error": "invalid_request"
            })));
        }
    };

    // Treat the plaintext as a document ID; perform lookup without branching on validity
    let doc_id = match std::str::from_utf8(&plaintext) {
        Ok(id) => id.trim_end_matches(char::from(0)), // strip padding artifacts safely
        Err(_) => {
            return Ok(HttpResponse::unprocessable_entity().json(serde_json::json!({
                "error": "invalid_request"
            })));
        }
    };

    // Firestore lookup; do not differentiate missing vs other errors via status code
    match db.get_doc_by_id::("resources", doc_id).await {
        Ok(Some(doc)) => Ok(HttpResponse::ok().json(doc)),
        Ok(None) => Ok(HttpResponse::unprocessable_entity().json(serde_json::json!({
            "error": "invalid_request"
        }))),
        Err(_) => Ok(HttpResponse::service_unavailable().json(serde_json::json!({
            "error": "service_unavailable"
        }))),
    }
}

Example 2: Avoiding timing leaks with constant-time checks and batched Firestore access

Use constant-time comparison where feasible and ensure Firestore calls do not reveal padding validity through latency or error type.

use actix_web::{web, HttpResponse, Result};
use firestore::FirestoreDb;
use subtle::ConstantTimeEq;

async fn post_secure_action(
    body: web::Json<serde_json::Value>,
    db: web::Data<FirestoreDb>,
) -> Result<HttpResponse> {
    let token = body.get("token").and_then(|v| v.as_str()).unwrap_or("");
    let expected_prefix = b"v1:abcdef"; // example constant prefix

    // Decode token without early branching on padding
    let decoded = match base64::decode(token) {
        Ok(d) => d,
        Err(_) => {
            return Ok(HttpResponse::bad_request().json(serde_json::json!({
                "error": "invalid_format"
            })));
        }
    };

    // Constant-time prefix check to avoid leaking valid vs invalid tokens
    let prefix_matches = if decoded.len() >= expected_prefix.len() {
        let slice = &decoded[0..expected_prefix.len()];
        CtOption::new(slice, slice.ct_eq(expected_prefix)).is_some()
    } else {
        false
    };

    if !prefix_matches {
        return Ok(HttpResponse::unprocessable_entity().json(serde_json::json!({
            "error": "invalid_token"
        })));
    }

    // Use the remainder as a document ID; Firestore call is unconditional
    let doc_id = hex::encode(&decoded[expected_prefix.len()..]);
    match db.get_doc_by_id::("entities", &doc_id).await {
        Ok(Some(doc)) => Ok(HttpResponse::ok().json(doc)),
        Ok(None) => Ok(HttpResponse::unprocessable_entity().json(serde_json::json!({
            "error": "invalid_token"
        }))),
        Err(_) => Ok(HttpResponse::service_unavailable().json(serde_json::json!({
            "error": "service_unavailable"
        }))),
    }
}

Key remediation practices include:

• Use a single error response (e.g., 400 or 404 with a generic message) for both decryption failures and missing Firestore documents.
• Perform Firestore lookups unconditionally when the ciphertext is structurally valid, avoiding early returns that create timing or status-code oracles.
• Apply constant-time operations for any comparison of sensitive material, and avoid branching on the result of padding verification before interacting with Firestore.
• Leverage middleBrick scans to identify inconsistent error handling and data exposure findings that may indicate an oracle risk in the API surface.

These patterns align with remediation guidance for OWASP API Top 10 cryptographic failures and help ensure that the Actix + Firestore combination does not inadvertently expose a padding oracle.