Email Injection in Axum with Basic Auth

Email injection occurs when user-controlled data is placed directly into email headers without validation or sanitization, enabling attackers to inject additional headers or obfuscate the intended recipient. In Axum, this risk is amplified when Basic Auth is used for authentication but is not coupled with strict input validation on any user-derived fields that eventually influence email handling downstream.

Basic Auth in Axum is often implemented to protect an endpoint, yet the application may still accept user input for email headers, message fields, or API parameters that are later passed to an email service. If an attacker authenticates with a valid Basic Auth credential but supplies crafted email values (e.g., in a request body or header), they can exploit improper concatenation to inject newline characters (%0A, %0D) into the email message. These injected lines can add recipients (cc/bcc), inject custom MIME headers like X-Originating-IP, or alter the subject and body in ways that bypass logging or monitoring.

For example, an endpoint that accepts a JSON payload with an email field and uses Basic Auth for access control may inadvertently forward the value to a mailer without normalization. A payload like { "to": "[email protected]\nCc: [email protected]" } can result in the message being sent to both parties if the server-side mail library does not enforce strict header separation. In Axum, this typically surfaces when route handlers compose messages using string interpolation or concatenation rather than validated models or dedicated email libraries that enforce header integrity.

The combination of Basic Auth and email handling creates a false sense of security: authentication protects the entry point, but not the content derived from the request. Since Axum does not implicitly sanitize user input, developers must explicitly validate and encode any data that may affect email headers. Without such controls, scanners using techniques like active prompt injection-style probes (adapted for email contexts) can identify injection points by observing whether injected headers are reflected or acted upon. Findings from such scans map to common weaknesses in the OWASP API Top 10 and can align with compliance checks in frameworks such as PCI-DSS when email logs are involved.

Remediation begins with treating email fields as structured data, not free-form strings. Use strongly typed models for request payloads, validate each field against strict patterns, and avoid inserting user input directly into headers. When integrating with mailers, prefer builder-style APIs that separate recipients, subject, and body rather than constructing raw messages. middleBrick can detect these issues by correlating runtime behavior with OpenAPI/Swagger specs, including $ref resolution, and highlighting risky patterns in unauthenticated scans, providing prioritized findings with severity and remediation guidance.

Securing Axum endpoints with Basic Auth while preventing email injection requires disciplined validation and separation of concerns. Below are concrete code examples that demonstrate safe handling when Basic Auth is in use.

use axum::{
    async_trait,
    extract::{Request, State},
    http::header,
    response::IntoResponse,
    routing::post,
    Json, Router,
};
use basic_auth::{AuthScheme, Credentials};
use headers::authorization::Basic;
use serde::{Deserialize, Serialize};
use validator::Validate;

// 1) Define a validated request model
#[derive(Debug, Deserialize, Validate)]
struct EmailRequest {
    #[validate(email(message = "must be a valid email address"))]
    to: String,
    #[validate(length(max = 200))]
    subject: String,
    #[validate(length(max = 5000))]
    body: String,
}

// 2) Basic Auth extractor wrapper that does not leak credentials into business logic
async fn validate_auth(request: Request) -> Result, (StatusCode, String)> {
    let auth_header = request.headers().get(header::AUTHORIZATION)
        .and_then(|h| h.to_str().ok())
        .and_then(|s| s.strip_prefix("Basic "))
        .unwrap_or("");

    // Decode and validate credentials (example: simple check)
    let decoded = base64::decode(auth_header).map_err(|_| (StatusCode::UNAUTHORIZED, "Invalid auth"))?;
    let creds = String::from_utf8(decoded).map_err(|_| (StatusCode::UNAUTHORIZED, "Invalid utf8"))?;
    let parts: Vec<&str> = creds.split(':').collect();
    if parts.len() != 2 || parts[0] != "admin" || parts[1] != "secret" {
        return Err((StatusCode::UNAUTHORIZED, "Bad credentials".to_string()));
    }
    Ok(request)
}

// 3) Handler with strict validation and safe email composition
async fn send_email(Json(payload): Json) -> impl IntoResponse {
    // Use a builder-style mailer; never concatenate user input into headers
    let email_builder = EmailBuilder::new()
        .to(payload.to.parse().expect("validated by validator"))
        .subject(&payload.subject)
        .body(&payload.body);

    // Send via your mailer (e.g., lettre)
    // mailer.send(email_builder.build()).await;

    (StatusCode::OK, "queued")
}

// 4) Router integrating auth and handler
fn app_router() -> Router {
    Router::new()
        .route("/send", post(move |req: Json| async move {
            // In practice, use a middleware or extractor for auth
            send_email(req).await
        }))
}