Open Redirect in Actix with Mongodb

An Open Redirect in an Actix web service that uses Mongodb as a backend can occur when user-controlled data from a Mongodb document is used to construct a redirect response without validation. For example, an endpoint may retrieve a document containing a redirect_url field and issue an HTTP redirect without verifying that the URL is safe. Because Mongodb stores application data that may come from untrusted sources, an attacker who can write or influence a document may be able to inject a malicious redirect target.

In Actix, a handler might query Mongodb and directly use a stored value in an HttpResponse::Found() location header. Because the redirect decision is based on data persisted in Mongodb, the threat is not merely a reflected input issue; it becomes a stored open redirect that can persist across deployments and affect any user who follows a link from the application. Common patterns include account settings pages that store a return-to URL in a Mongodb collection or email templates that reference a redirect stored in the database.

Open Redirect is listed among the OWASP API Top 10 as a common web vulnerability. When combined with Mongodb, the risk is that the database becomes a vector for storing attacker-controlled redirect targets. If an API endpoint uses an OpenAPI spec that does not document or enforce constraints on redirect parameters, middleBrick’s checks for Property Authorization and Input Validation may flag the absence of strict allowlists for redirect destinations. Because middleBrick scans unauthenticated attack surfaces and includes Property Authorization and Input Validation among its 12 parallel checks, it can surface such misconfigurations without requiring credentials.

An example attack flow: an application stores a user profile in Mongodb with a field like preferred_redirect. The Actix handler reads this field and redirects the user without verifying it is a same-origin or approved absolute URL. An attacker who can update their own profile (or, in some cases, influence another user’s document via IDOR or BOLA) can set this field to a phishing site. Subsequent requests that trigger the redirect will send victims to the attacker-controlled location, leveraging trust in the originating domain.

To remediate Open Redirect when using Mongodb with Actix, validate and normalize any redirect target derived from Mongodb documents. Use an allowlist of permitted domains or enforce that redirect URLs be absolute and point only to trusted origins. Below are concrete code examples showing safe patterns in Actix with a Mongodb backend.

First, define a helper that validates a redirect URL against a strict allowlist and rejects non-http(s) schemes and unexpected hosts:

use actix_web::{HttpResponse, http::header::LOCATION};
use url::Url;

fn safe_redirect_url(input: &str, allowed_hosts: &[&str]) -> Option {
    let parsed = Url::parse(input).ok()?;
    if parsed.scheme() != "http" && parsed.scheme() != "https" {
        return None;
    }
    if !allowed_hosts.contains(&parsed.host_str()?) {
        return None;
    }
    Some(parsed.into())
}

Next, use this helper in an Actix handler that retrieves a document from Mongodb. This example assumes a Mongodb collection where documents may contain a redirect_target field; the handler only follows the stored value if it passes validation:

use actix_web::web;
use mongodb::{bson::doc, options::FindOneOptions};

async fn get_redirect(
    db: web::Data<mongodb::Database>,
    user_id: String,
) -> Result<HttpResponse, actix_web::Error> {
    let coll = db.collection("user_prefs");
    let filter = doc! { "user_id": user_id };
    let opts = FindOneOptions::builder().build();
    let doc = coll.find_one(filter, opts).await.map_err(|_| actix_web::error::ErrorInternalServerError("db error"))?;

    let allowed_hosts = ["app.example.com", "static.example.com"];
    if let Some(item) = doc {
        if let Some(target) = item.get_str("redirect_target").ok().and_then(|s| safe_redirect_url(s, &allowed_hosts)) {
            return Ok(HttpResponse::Found()
                .insert_header((LOCATION, target))
                .finish());
        }
    }
    Ok(HttpResponse::Found()
        .insert_header((LOCATION, "/fallback"))
        .finish())
}

For applications that accept user-supplied redirect parameters in addition to stored values, apply the same validation before merging stored and supplied data. Always treat values retrieved from Mongodb as untrusted inputs, and avoid constructing Location headers from concatenated strings that include raw database content without allowlist checks. These patterns reduce the risk of Open Redirect while preserving legitimate redirect flows.