Email Injection in Actix with Firestore

Email injection occurs when user-controlled data is embedded into email headers or message bodies without proper validation or encoding. In an Actix web application that uses Firestore as a backend, the risk arises when developer code passes unchecked input (for example, a user-supplied name or email address) directly into email-related operations such as message headers, recipient fields, or transactional email templates. Because Firestore stores and retrieves data used by Actix services, any malicious payload stored or retrieved from Firestore can later be injected into email contexts if the downstream code does not sanitize or encode values.

Consider an Actix handler that creates a welcome email using data retrieved from Firestore. If the application stores a user profile containing a displayName field supplied by the user and then uses that value in an email header or body without sanitization, an attacker may provide a displayName like Smith\r\nCC: attacker@example.com. When the email is constructed, the CRLF sequence can split the header and inject an additional recipient. Firestore does not perform email-specific validation; it stores the data as provided. The vulnerability is therefore in the Actix code that reads from Firestore and formats emails, not in Firestore itself. However, the presence of Firestore as a persistent data store increases the impact: injected emails can be sent to multiple recipients, or malicious content can be persisted and reused across multiple campaigns.

Common attack patterns include adding extra recipients (CC/BCC), injecting fake reply-to addresses, or inserting newline characters that cause header splitting. In a Firestore-backed Actix service, this often maps to the OWASP API Top 10 category '2023-A01: Broken Access Control' when email functions expose sensitive operations, and can lead to phishing or spam amplification. Because middleBrick tests unauthenticated attack surfaces and includes checks for Input Validation and Unsafe Consumption, such flows can be detected when user-controlled data from Firestore reaches endpoints that generate emails. Remediation centers on strict input validation, safe encoding for email headers and bodies, and avoiding direct concatenation of user data into email constructs.

Secure Actix services that use Firestore should treat all user data as untrusted, including values read from Firestore documents. The following examples show how to structure Actix handlers and Firestore interactions safely. Use a dedicated email library that handles header encoding (such as the mailparse or lettre ecosystem in Rust) and never build email headers by string concatenation with user input.

First, retrieve user data from Firestore without assuming its safety. The Firestore client for Rust typically deserializes documents into strongly typed structs. Define your structs explicitly and avoid raw string concatenation for email fields.

use firestore::FirestoreDb; use serde::Deserialize;

#[derive(Deserialize)]
struct UserProfile {
    email: String,
    display_name: String,
}

async fn get_user_profile(db: &FirestoreDb, user_id: &str) -> Option {
    db.get_as::(&format!("users/{}", user_id)).await.ok()
}

Second, when composing emails, use a safe email builder that properly encodes headers. The lettre crate provides types such as Mailbox and Address that validate and encode email addresses and display names. For example:

use lettre::message::Mailbox;

fn build_welcome_email(user: &UserProfile) -> Result {
    let mailbox = Mailbox::new(Some(user.display_name.as_str()), user.email.parse()?);
    Ok(mailbox)
}

Third, if you must include user data in email bodies (e.g., HTML templates), use a templating engine that performs context-aware escaping (e.g., askama or tera) to prevent header or body injection. For instance, with Askama:

<!-- templates/welcome.html -->
<h1>Welcome, {{ user.display_name | e }}</h1>
<p>Your email is: {{ user.email | e }}</p>

Finally, apply strict validation on any input that enters Firestore. Reject or sanitize values containing newline characters or other control characters before storing them. This reduces the risk that stored data can later be used maliciously in email contexts. middleBrick scans can help identify endpoints where unsanitized Firestore data reaches email-related functionality, providing prioritized findings and remediation guidance.