Open Redirect in Actix with Dynamodb

An Open Redirect in an Actix web service that uses DynamoDB as a backend store typically arises when an application accepts a user-supplied URL or redirect target and stores or logs it before using DynamoDB to retrieve additional configuration or user data. If the redirect target is not validated and the application uses DynamoDB queries to resolve or look up redirect policies, an attacker can supply a malicious URL that causes the service to redirect victims to arbitrary destinations.

In this setup, the vulnerability is not in DynamoDB itself but in how Actix handles incoming parameters that influence redirect behavior and how those parameters are cross-referenced with data stored in DynamoDB. For example, an endpoint like /login might accept a redirect_uri query parameter, validate it loosely, then query DynamoDB for tenant- or client-specific redirect allowlists. If the validation is weak and the DynamoDB lookup is used to decide whether to trust the supplied URI, an attacker can bypass intended allowlists by supplying a URI that passes initial checks but resolves to a malicious site through a misconfigured or overly permissive DynamoDB entry.

Because middleBrick scans the unauthenticated attack surface, it can detect indicators such as missing strict validation on redirect parameters, missing referer or origin checks, and DynamoDB query patterns that return redirect rules without tight constraints. These findings highlight where an Actix service using DynamoDB may expose an Open Redirect: user input influences both the redirect decision and the DynamoDB query, and if either is weak, the combined behavior becomes unsafe.

Real-world analogs in the OWASP API Top 10 include Improper Neutralization of Input During Web Page Generation (A01:2021) and Security Misconfiguration. An example CVE pattern is similar to CVE-2021-28627 where insufficient validation of redirect targets leads to phishing-prone behavior. In an Actix + DynamoDB context, ensure that redirect URIs are validated against a strict allowlist stored in DynamoDB with exact-match conditions and that the service does not automatically follow user-provided locations without server-side confirmation.

Remediate Open Redirect risks in Actix by strictly validating user input before using it in redirects and by enforcing precise DynamoDB query constraints. Do not rely on client-supplied values for security decisions; instead, resolve allowed redirect targets from DynamoDB using exact identifiers, and map validated identifiers to canonical URIs on the server.

Example: store allowed redirect URIs or identifiers in DynamoDB and query by a known client ID rather than by raw user input. Use parameterized queries to avoid injection issues and ensure the response is checked before any redirect.

use actix_web::{web, HttpResponse, Result};
use aws_sdk_dynamodb::Client;
use serde::Deserialize;

#[derive(Deserialize)]
struct RedirectRequest {
    client_id: String,
    // Do not accept raw redirect_uri from the client for decision-making
}

async fn safe_redirect(
    payload: web::Json,
    client: web::Data,
) -> Result {
    let client_id = &payload.client_id;

    // Query DynamoDB for allowed redirect configuration using a key condition
    let output = client
        .get_item()
        .table_name("redirect_policies")
        .key("client_id", aws_sdk_dynamodb::types::AttributeValue::S(client_id.clone()))
        .send()
        .await
        .map_err(|_| actix_web::error::ErrorInternalServerError("DynamoDB error"))?;

    let item = output.item().ok_or_else(|| actix_web::error::ErrorNotFound("Policy not found"))?;
    let allowed_uri = item.get("allowed_uri")
        .and_then(|v| v.as_s().ok())
        .ok_or_else(|| actix_web::error::ErrorBadRequest("Invalid policy"))?;

    // Server-side canonical redirect; do not follow user-provided locations
    Ok(HttpResponse::Found()
        .header("Location", allowed_uri)
        .finish())
}

In this pattern, the client provides an identifier (e.g., client_id), not the final redirect URL. The Actix service queries DynamoDB for that identifier’s allowed target and performs the redirect to the server-defined URI. This removes the ability for an attacker to inject arbitrary URLs while still leveraging DynamoDB to manage policy.

Additional hardening steps include rejecting malformed URLs, enforcing HTTPS for redirect targets, and avoiding the use of 307/302 for user-controlled destinations. middleBrick can help identify whether your Actix endpoints exhibit patterns where user input influences both redirect logic and DynamoDB queries, providing prioritized findings and remediation guidance.