Open Redirect in Axum with Api Keys

An open redirect occurs when an application redirects a user to an arbitrary URL supplied in the request. In Axum, combining redirect logic with API key handling can unintentionally expose this behavior if the redirect target is derived from user-controlled data such as query parameters or headers without strict validation. An API key is often used to authenticate requests; if the API key is accepted but the redirect destination is not rigorously validated, an attacker can supply a valid API key and a malicious URL to craft a phishing link that appears legitimate.

Consider an Axum handler that accepts an api_key query parameter and a url parameter for post-login redirection. If the handler only verifies the API key’s presence and does not enforce an allowlist or strict pattern matching on the url, an attacker can provide a keyed request to a trusted endpoint that then redirects to a malicious site. This becomes a phishing vector because the API key may be logged or leaked in referrer headers, and users may trust the domain due to its association with your service. The handler may intend to redirect users after authentication, but without validating the destination, the API key inadvertently authorizes the redirection to any location.

In practice, this misconfiguration maps to the OWASP API Security Top 10:2023 Security Misconfiguration and can be probed by unauthenticated scanning tools like middleBrick, which tests for open redirects as part of its 12 parallel security checks. middleBrick can detect whether a provided API key enables redirection to external domains and surface the finding with severity and remediation guidance without requiring authentication.

Example of a vulnerable Axum handler:

use axum::{routing::get, Router, http::StatusCode};
use std::net::SocketAddr;

async fn handler(
    Query(params): Query<HashMap>
) -> (StatusCode, HeaderMap) {
    let api_key = params.get("api_key").ok_or(StatusCode::UNAUTHORIZED)?;
    if !validate_key(api_key) {
        return Err((StatusCode::UNAUTHORIZED, HeaderMap::new()));
    }
    let redirect_url = params.get("url").unwrap_or("/");
    // Vulnerable: no validation of redirect_url
    (StatusCode::FOUND, build_redirect_header(redirect_url))
}

An attacker with a valid API key can set url to a phishing domain, and the handler will issue a 302 to that destination. middleBrick’s unauthenticated scan would flag this as an open redirect finding, highlighting the missing destination validation despite the presence of an API key check.

Secure remediation centers on strict validation of the redirect target and scoping the API key usage to authentication only, not authorization for navigation. Do not allow open redirects when a key is accepted; treat the key as proof of identity, not as permission to follow arbitrary client-provided locations.

1) Use an allowlist of trusted domains or paths for redirects. If redirection is necessary, resolve relative paths only and reject any URL that does not match a strict pattern. Do not forward the url parameter directly to a redirect response.

2) Prefer returning a fixed, known-safe response (such as a JSON body with a client-side redirect URL configured server-side) rather than echoing user input. If you must redirect, ensure the target is a relative path or a fully validated absolute path within your host.

3) Ensure API key validation is separate from routing logic; do not let successful key validation imply trust in other parameters.

Secure Axum handler example:

use axum::{routing::get, Router, http::StatusCode, response::Redirect};
use std::net::SocketAddr;

async fn handler(
    Query(params): Query<HashMap>
) -> Result<Redirect, (StatusCode, &'static str)> {
    let api_key = params.get("api_key").ok_or((StatusCode::UNAUTHORIZED, "missing api_key"))?;
    if !validate_key(api_key) {
        return Err((StatusCode::UNAUTHORIZED, "invalid api_key"));
    }
    // Safe: redirect only to a known internal path; no user-controlled URL
    Ok(Redirect::to("/dashboard"))
}

fn validate_key(key: &str) -> bool {
    // Compare against stored key(s) using constant-time comparison in production
    key == "YOUR_API_KEY_HERE"
}

If your application must support third-party integrations that require redirect URLs, do not accept free-form URLs from untrusted sources. Instead, map opaque tokens to pre-registered redirect destinations server-side, and have the client supply only the token. This preserves the utility of API keys for authentication while eliminating the redirect risk. middleBrick’s CLI can be used in CI/CD to assert that no open redirect patterns remain in your routes; the GitHub Action can fail builds if such patterns are detected before deployment.