Open Redirect in Actix with Bearer Tokens

An Open Redirect in Actix combined with Bearer Token handling can lead to situations where an authenticated token is unintentionally passed to a malicious destination. This typically occurs when a handler accepts a user-controlled URL or location parameter and issues a redirect without strict allowlisting of target hosts. If the handler also propagates or logs authorization headers, a Bearer token may be exposed in logs, browser history, or referrer headers after the redirect. Attackers can craft links that trick users into following a redirect while carrying a valid token, enabling token leakage or phishing scenarios.

Consider a pattern where an API endpoint accepts a next query parameter to redirect clients after authentication. In Actix, if the redirect logic does not validate the target origin, an attacker can supply a URL such as https://evil.com and induce the client’s browser to navigate there with an Authorization header present. Even if the redirect is performed server-side, logging middleware or error handlers might record headers, inadvertently exposing the Bearer token. This behavior is especially relevant when token propagation relies on headers rather than opaque session references.

Real-world examples include integrations where third-party services redirect back to your Actix application with tokens in query strings or fragments. Although OAuth 2.0 recommends using the code flow with PKCE, misconfigured routes can still leak tokens via open redirects. The risk is compounded when redirects are used for post-login landing pages without strict host validation. MiddleBrick’s checks for BOLA/IDOR and Unsafe Consumption help surface such routing issues by correlating endpoint definitions with runtime behavior, including header handling.

In a black-box scan, middleBrick tests whether an endpoint accepts a redirect target and whether sensitive headers like Authorization are reflected or persisted across redirects. The tool’s LLM/AI Security checks do not apply here, but the scanner’s Inventory Management and Unsafe Consumption checks can identify routes that combine redirects with token-bearing requests. Findings include severity ratings and remediation guidance, emphasizing host allowlists and avoiding header propagation to redirect responses.

Using the CLI, you can verify your endpoints by running middlebrick scan <url> and reviewing any flagged findings related to redirects or header exposure. The Web Dashboard provides per-category breakdowns, allowing you to track changes over time. For teams on the Pro plan, continuous monitoring can alert you when new open redirect patterns appear, integrating checks into CI/CD pipelines via the GitHub Action to fail builds if risk thresholds are exceeded.

Remediation focuses on two areas: preventing open redirects and ensuring Bearer tokens are not inadvertently exposed during redirects. First, never use user-controlled input directly in a redirect response. Instead, validate the target host against a strict allowlist and prefer internal route names or IDs over raw URLs. Second, ensure that Authorization headers are not copied into redirect responses or logged in scenarios where a redirect occurs.

Below is a secure Actix example that avoids open redirects and protects Bearer tokens. The handler resolves a known internal destination based on a validated identifier and returns a 303 See Other without propagating headers.

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

fn approved_redirect(target: &str) -> Option<&'static str> {
    match target {
        "dashboard" => Some("https://app.example.com/dashboard"),
        "settings"  => Some("https://app.example.com/settings"),
        _           => None,
    }
}

async fn post_login_redirect(
    web::Query(params): web::Query>,
) -> impl Responder {
    // Do not use user-provided URL directly
    let next = params.get("next");
    let target = match next.and_then(|n| approved_redirect(n.as_str())) {
        Some(url) => url,
        None      => "https://app.example.com/home",
    };

    // Build response without Authorization header
    let mut resp = HttpResponse::SeeOther();
    resp.insert_header(("Location", target));
    // Ensure no sensitive cookies or headers are added
    resp.finish()
}

If you must accept a full URL, enforce host allowlisting and reject non-matching origins. Do not include Bearer tokens in query parameters or fragments, as they can leak in logs and browser history.

For applications using middleware that attaches Bearer tokens to requests, ensure that redirect responses do not forward authentication headers. Actix middleware can inspect responses and strip or avoid copying Authorization headers when the status indicates a redirect.

In the CLI, after scanning with middlebrick scan <url>, review findings for BOLA/IDOR and Unsafe Consumption. The Web Dashboard will show these findings with severity levels and specific guidance. Teams on the Pro plan can enable continuous monitoring so that future changes to these routes trigger alerts, and the GitHub Action can block merges if a new open redirect is detected.

Finally, consider using opaque tokens or session identifiers instead of embedding Bearer tokens in URLs. Combine this with server-side session stores and strict referrer policies to reduce the impact of any accidental leakage. The MCP Server allows you to run scans directly from compatible IDEs, making it easier to validate fixes during development.