Email Injection in Axum with Api Keys

Email Injection is a class of injection vulnerability where attacker-controlled data is used to manipulate email headers or the address fields in an email-sending flow. In Axum, this typically occurs when user input is directly concatenated into email header values such as To, Cc, Reply-To, or Subject without validation or sanitization. When Api Keys are used for authorization, developers may assume that authentication alone limits who can trigger email-sending endpoints. However, if the endpoint accepts user-controlled data for email headers and does not validate or encode it, an authenticated or unauthenticated attacker can inject additional headers or obfuscate the intended recipient list.

Consider an Axum handler that builds an email based on query or body parameters while also requiring an Api Key in a header for access control:

// Hypothetical Axum handler vulnerable to Email Injection
async fn send_email(
    ApiKey(key) : ApiKey,
    Form(params): Form,
) -> impl IntoResponse {
    let email = format!(
        "To: {}\nSubject: {}\n\n{}",
        params.to, params.subject, params.body
    );
    // send_email would use the key for some internal auth/audit
    sendgrid::send(email).map_err(|e| ...)?;
    Ok(()) 
}

If params.to or params.subject contains newline characters (e.g., attacker@example.com\nCc: victim@evil.com), the injected lines become additional email headers. This can redirect copies of the message, enable spoofed headers, or facilitate phishing via a seemingly authorized request. Api Keys identify the caller but do not constrain the content of the email, so the authentication mechanism does not mitigate the injection. In a black-box scan, middleBrick tests such injection patterns against endpoints that use header-based authentication like Api Keys and reports the finding under Authentication and Input Validation checks, highlighting the missing canonicalization and header separation.

Because Axum does not provide built-in header sanitization, developers must treat any user input used in email composition as untrusted. The presence of Api Keys should not reduce validation rigor; they only confirm who is making the request, not whether the request’s data is safe. middleBrick’s checks for BFLA/Privilege Escalation and Input Validation help surface these risks when scanning an Axum API that uses header-based keys without output encoding.

Remediation focuses on strict validation, canonicalization, and avoiding direct concatenation of user input into email headers. In Axum, you can enforce allowlists for recipients, sanitize newlines, and use structured email libraries that separate headers from content. Below are two concrete, working Axum examples that demonstrate secure handling when combined with Api Keys.

1) Validate and sanitize headers, reject newlines

Ensure that any user input used in email headers is stripped of carriage returns and line feeds. Use an allowlist for recipients (e.g., verified domains or internal user IDs) rather than raw free-form strings.

use axum::{routing::post, Router, extract::Extension, http::StatusCode};
use serde::Deserialize;

#[derive(Deserialize)]
struct EmailParams {
    to: String,
    subject: String,
    body: String,
}

/// Validate that a string contains no newline or carriage return characters.
fn is_safe_header_value(value: &str) -> bool {
    !value.contains('\n') && !value.contains('\r')
}

async fn send_email(
    ApiKey(key) : ApiKey,
    Form(params): Form,
) -> Result {
    // Example allowlist check for recipient domain
    if !params.to.ends_with("@yourcompany.com") {
        return Err((StatusCode::BAD_REQUEST, "Invalid recipient".into()));
    }
    if !is_safe_header_value(¶ms.to) || !is_safe_header_value(¶ms.subject) {
        return Err((StatusCode::BAD_REQUEST, "Header contains invalid characters".into()));
    }

    // Use a library that separates headers from body, e.g., lettre
    use lettre::message::{Mailbox, MessageBuilder};
    use lettre::transport::smtp::authentication::Credentials;
    use lettre::{SmtpTransport, Transport};

    let from = Mailbox::new(None, "sender@yourcompany.com".parse().unwrap());
    let to = Mailbox::new(None, params.to.parse().unwrap());
    let email = MessageBuilder::new()
        .from(from)
        .to(to)
        .subject(params.subject)
        .body(params.body)
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    let creds = Credentials::new("smtp_user".to_string(), "smtp_pass".to_string());
    let mailer = SmtpTransport::relay("smtp.example.com")
        .unwrap()
        .credentials(creds)
        .build();

    match mailer.send(&email) {
        Ok(_) => Ok(StatusCode::OK),
        Err(e) => Err((StatusCode::INTERNAL_SERVER_ERROR, e.to_string())),
    }
}

fn main() {
    let app = Router::new()
        .route("/email", post(send_email))
        .layer(Extension(ApiKeyValidator));
    // run(app)
}

2) Use structured templates for email composition

Instead of building email text via string concatenation, define templates that keep headers separate from user-provided content. This prevents injection even if newline characters appear in user input.

use askama::Template;

#[derive(Template)]
#[template(path = "email.txt")]
struct EmailTemplate {
    to: String,
    subject: String,
    body: String,
}

async fn send_email(
    ApiKey(key) : ApiKey,
    Form(params): Form,
) -> Result {
    // Further validation as above
    if !params.to.ends_with("@yourcompany.com") {
        return Err((StatusCode::BAD_REQUEST, "Invalid recipient".into()));
    }
    let tmpl = EmailTemplate {
        to: params.to,
        subject: params.subject,
        body: params.body,
    };
    let email_body = tmpl.render().map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    // Use a safe email library to send; headers are controlled by the template, not user input
    Ok(StatusCode::OK)
}

These approaches ensure that Api Keys remain a valid access control while user input cannot alter the email envelope. middleBrick will reflect improved scores under Authentication and Input Validation when such canonicalization and separation are in place.