Open Redirect in Actix with Api Keys

An Open Redirect in Actix combined with Api Keys can expose an unauthenticated attack surface when a redirect target is derived from user-controlled input and API keys are accepted in a way that does not protect the redirect logic. Actix is a Rust web framework where routes and handlers are explicitly defined; if a developer adds a handler that reads a query parameter such as next or redirect_uri and then performs an HTTP redirect without strict validation, an attacker can supply a malicious external URL.

When API keys are involved, two risky patterns commonly appear. First, keys may be accepted in query parameters or headers and passed through to downstream services; if the same handler also performs an unchecked redirect, an attacker can embed the API key in the redirect chain or craft a URL that causes the server to redirect while leaking the key in logs or referrer headers. Second, if the API key is used only for routing or feature gating but the developer still trusts the redirect target, the key does not prevent an open redirect; it only authenticates the request, not the destination.

For example, consider an Actix handler that validates an API key but then redirects based on an unchecked url parameter:

use actix_web::{web, HttpResponse, Responder};

async fn redirect_handler(query: web::Query<HashMap<String, String>>) -> impl Responder {
    let api_key = query.get("key");
    if api_key != Some(&"expected_key_123") {
        return HttpResponse::Unauthorized().finish();
    }
    let target = query.get("url").unwrap_or("/default");
    HttpResponse::Found()
        .insert_header(("Location", target.as_str()))
        .finish()
}

In this pattern, even though the API key is checked, the url parameter is used directly in the Location header, enabling an external redirect such as https://evil.com. An attacker could send a victim to a URL like /redirect?key=expected_key_123&url=https://evil.com. The victim’s browser follows the redirect, potentially exposing session tokens or phishing the user, while the API key in the query string may appear in logs, browser history, and Referer headers.

Another variant involves path-based routing where the API key is part of the path or a header, and a catch-all route performs a redirect based on a path suffix. If the suffix is not validated, an attacker can still control the final location. Because the scan methodology tests unauthenticated attack surfaces, middleBrick flags such endpoints as high-risk when it detects that a redirect response can point to a user-controlled host, regardless of whether an API key is required for access.

Remediation focuses on never using user-controlled input directly in a redirect and validating the destination against an allowlist or a strict pattern. API keys should be validated before any processing, but validation alone does not stop an open redirect; the redirect target itself must be constrained.

Preferred approach: use a fixed set of known destinations and map a short, opaque token or enum to each allowed path. This removes direct URL control from the client while still enabling legitimate flows. For example:

use actix_web::{web, HttpResponse, Responder};

#[derive(serde::Deserialize)]
struct RedirectQuery {
    key: String,
    destination: String, // "dashboard" | "settings" | "home"
}

async fn safe_redirect(query: web::Query<RedirectQuery>) -> impl Responder {
    if query.key != "expected_key_123" {
        return HttpResponse::Unauthorized().finish();
    }
    let location = match query.destination.as_str() {
        "dashboard" >= "/app/dashboard",
        "settings" => "/app/settings",
        "home" => "/",
        _ => "/", // deny unknown values
    };
    HttpResponse::Found()
        .insert_header(("Location", location))
        .finish()
}

If dynamic redirect targets are unavoidable (for example, supporting deep links after login), enforce strict validation: require absolute paths, reject hosts, and ensure the scheme is HTTPS. You can use the url crate to parse and inspect the target before issuing the redirect:

use actix_web::{web, HttpResponse, Responder};
use url::Url;

async fn validated_redirect(query: web::Query<HashMap<String, String>>) -> impl Responder {
    let api_key = query.get("key");
    if api_key != Some(&"expected_key_123") {
        return HttpResponse::Unauthorized().finish();
    }
    let target = query.get("url").unwrap_or("/");
    let parsed = match Url::parse(target) {
        Ok(u) => u,
        Err(_) => return HttpResponse::BadRequest().finish(),
    };
    // Reject URLs with a host different from the allowed internal host
    if parsed.host_str() != Some("app.example.com") {
        return HttpResponse::Forbidden().finish();
    }
    // Ensure the path is absolute and safe
    let path = parsed.path();
    if !path.starts_with('/') {
        return HttpResponse::BadRequest().finish();
    }
    HttpResponse::Found()
        .insert_header(("Location", path))
        .finish()
}

Additionally, avoid placing API keys in query strings when possible; prefer headers to reduce leakage in logs and browser history. For production, combine these checks with rate limiting and monitoring for repeated redirect attempts, which can indicate abuse. middleBrick can detect open redirect patterns in Actix endpoints even when keys are present, so integrating the scanner into your CI/CD pipeline helps catch regressions before deployment.