Open Redirect in Axum with Mongodb

An open redirect in an Axum application that uses MongoDB typically arises when a route accepts a user-supplied URL or path parameter and redirects the client without strict validation. If the application stores or retrieves redirect targets from MongoDB—such as a configured destination, marketing link, or user profile field—lack of validation on the stored value can lead to an open redirect. An attacker might craft a request that leverages a vulnerable endpoint and a malicious MongoDB entry to send users to arbitrary sites.

In this combination, the web framework (Axum) provides the routing and response generation, while MongoDB serves as the data store for redirect configuration or parameters. The vulnerability is not in MongoDB itself, but in how the application uses data retrieved from MongoDB to perform HTTP redirects. For example, an endpoint like /go?key=promo might look up a target URL in MongoDB and issue a redirect. If the stored URL is user-controlled and not validated, the application becomes an open redirector. Attackers can also probe for open redirects to aid in phishing or cache poisoning, and the presence of MongoDB does not inherently mitigate or cause the issue; it is the unchecked use of retrieved data in Axum’s redirect logic that matters.

An example attack flow: an authenticated or unauthenticated user manages a record in MongoDB that contains a redirect URL. If the application trusts this value and uses it directly in an Axum redirect response (e.g., returning an HTTP 302 with the stored URL), an attacker who can modify that record can redirect victims to malicious domains. This becomes more impactful when combined with social engineering, as the apparent origin (your domain) is preserved in the redirect chain. Because the scan checks for open redirects as part of its 12 parallel security checks, such misconfigurations are detectable when a response redirects to a non-origin host without strict allowlists.

Remediation focuses on validating and constraining redirect targets at the application layer, regardless of the data source. When using MongoDB with Axum, treat every stored URL as untrusted and enforce allowlists or strict patterns before using it in a redirect. Below are concrete code examples for Axum with the official MongoDB Rust driver.

1. Validate against an allowlist of permitted domains

Only allow redirects to known, safe domains. Use the url crate to parse and check the host.

use axum::{http::StatusCode, response::Redirect};
use url::Url;

async fn redirect_handler(target_key: String) -> Result {
    // Fetch the stored URL from MongoDB by key (pseudo-code)
    let stored_url = fetch_redirect_url_from_mongodb(&target_key).await;

    let url = match stored_url {
        Some(u) => u,
        None => return Err((StatusCode::NOT_FOUND, "Target not found".into())),
    };

    let parsed = Url::parse(&url).map_err(|_| (StatusCode::BAD_REQUEST, "Invalid URL".into()))?;
    let host = parsed.host_str().ok_or_else(|| (StatusCode::BAD_REQUEST, "No host"))?;

    // Allowlist check
    match host {
        "app.example.com" | "static.example.com" => {
            Ok(Redirect::temporary(parsed.as_str()))
        }
        _ => Err((StatusCode::FORBIDDEN, "Redirect target not allowed".into())),
    }
}

async fn fetch_redirect_url_from_mongodb(key: &str) -> Option {
    // Example MongoDB collection fetch using the official driver
    use mongodb::{bson::doc, Client};
    // Assume client is initialized and connected
    let client = Client::with_uri_str("mongodb://localhost:27017").await.ok()?;
    let collection = client.database("myapp").collection::<(String, String)>("redirects");
    let filter = doc! { "key": key };
    let result = collection.find_one(filter, None).await.ok()?;
    result.map(|(_, url)| url)
}

2. Normalize and restrict URL schemes and paths

Reject non-HTTP(S) schemes and enforce path restrictions to prevent javascript: or other dangerous protocols.

fn is_safe_redirect(url_str: &str) -> bool {
    let parsed = match Url::parse(url_str) {
        Ok(u) => u,
        Err(_) => return false,
    };
    // Only allow http and https
    if parsed.scheme() != "http" && parsed.scheme() != "https" {
        return false;
    }
    // Optionally restrict to specific paths or hosts
    parsed.host_str().map_or(false, |h| h.ends_with("example.com"))
}

// In your handler:
if is_safe_redirect(&url) {
    Ok(Redirect::temporary(url))
} else {
    Err((StatusCode::BAD_REQUEST, "Unsafe redirect".into()))
}

3. Use parameterized configuration instead of user-supplied URLs

Store only path segments or keys in MongoDB and map them to full URLs server-side to avoid storing arbitrary redirect targets.

// MongoDB stores: { "key": "promo", "path": "/promotions/summer" }
async fn safe_promotion_redirect(key: String) -> Result {
    use mongodb::bson::doc;
    let client = Client::with_uri_str("mongodb://localhost:27017").await.map_err(|_| (StatusCode::INTERNAL_SERVER_ERROR, "DB error"))?;
    let collection = client.database("myapp").collection::<(String, String)>("promos");
    let filter = doc! { "key": &key };
    let doc = collection.find_one(filter, None).await.ok().flatten().ok_or_else(|| (StatusCode::NOT_FOUND, "Not found"))?;
    let path = doc.1; // e.g., "/promotions/summer"
    // Build a URL relative to a known base
    let base = "https://app.example.com";
    let full = format!("{}{}", base, path);
    Ok(Redirect::temporary(&full))
}

4. Logging and monitoring

Log suspicious redirect attempts and review MongoDB entries regularly to ensure no unauthorized modifications. Combine these checks with Axum middleware that validates outgoing redirect locations when responses have status 3xx.