Ssrf Server Side in Actix with Bearer Tokens

Server-Side Request Forgery (SSRF) in Actix applications becomes particularly risky when Bearer Tokens are used for upstream service authentication. In this combination, an attacker can leverage an SSRF flaw to make the server send requests to internal or external endpoints, presenting a valid Bearer Token that the backend service trusts. Because the token is carried in HTTP headers, an SSRF vulnerability can effectively proxy requests through the compromised Actix instance, bypassing network-level restrictions that would normally block direct access to internal services.

Actix-web is a high-performance Rust framework where routes and handlers are explicitly defined. If an endpoint accepts a URL from user input—such as a webhook target, image source, or health-check URL—and uses an HTTP client to fetch that URL, it may inadvertently allow an SSRF attack. When the Actix server includes an Authorization header with a Bearer Token, the SSRF becomes more dangerous: the attacker can force the server to access protected resources that require that token. Common examples include metadata services (e.g., cloud instance metadata at 169.254.169.254), internal Kubernetes APIs, or service meshes that rely on bearer-token authentication.

The risk is amplified when the Bearer Token has broad permissions or is long-lived. An SSRF that exfiltrates or modifies data using a valid token may not trigger the same alarms as an untrusted request. Because the token is presented by the server itself, the backend service has no way to distinguish a legitimate client request from a malicious one initiated via SSRF. This is why SSRF with Bearer Tokens is considered a high-severity pattern, often mapping to OWASP API Top 10 #4 (Insecure Design) and #5 (Broken Function Level Authorization).

Real-world CVEs such as CVE-2021-41773 (Apache HTTP Server path traversal and SSRF) demonstrate how SSRF can lead to unauthorized access. In an Actix context, similar issues arise when request building is not properly constrained. For instance, using a permissive HTTP client configuration that follows redirects or does not validate hostnames can allow an attacker to pivot to internal services. Input validation, hostname allowlists, and disabling automatic redirect handling are critical controls when Bearer Tokens are involved.

middleBrick scans can detect SSRF vulnerabilities in Actix APIs by analyzing OpenAPI specifications and runtime behavior. The tool checks whether user-controlled inputs are used in HTTP request functions and whether sensitive headers like Authorization are propagated to untrusted destinations. With its LLM/AI Security checks, it also probes for prompt injection and data exfiltration patterns that could complement SSRF attacks in AI-exposed endpoints.

Remediation focuses on preventing untrusted input from influencing HTTP requests that include Bearer Tokens. The safest approach is to avoid accepting target URLs from users entirely. If you must accept a URL, enforce strict allowlisting of hosts and paths, disable redirects, and do not propagate authentication headers to user-specified endpoints.

Below are concrete Actix-web examples that demonstrate insecure patterns and their secure counterparts.

Insecure Example: Proxy with Bearer Token and User-Supplied URL

use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use reqwest::Client;

async fn proxy_endpoint(query: web::Query impl Responder {
    let target = query.get("url").unwrap_or(&"http://localhost:8080".to_string());
    let token = "my-secret-bearer-token";

    let client = Client::new();
    let response = client
        .get(target)
        .bearer_auth(token)
        .send()
        .await
        .unwrap_or_else(|_| HttpResponse::BadGateway().finish());

    HttpResponse::Ok().body(response.text().await.unwrap_or_default())
}

This pattern is dangerous because target is user-controlled and the Bearer Token is always sent. An attacker can set url to an internal service and the server will relay the request with its token.

Secure Example: Fixed Internal Target with No User URL

use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use reqwest::Client;

async fn internal_health_check() -> impl Responder {
    let target = "http://internal-service/health"; // Fixed, hardcoded URL
    let token = "my-secret-bearer-token";

    let client = Client::new();
    let response = client
        .get(target)
        .bearer_auth(token)
        .send()
        .await
        .unwrap_or_else(|_| HttpResponse::ServiceUnavailable().finish());

    HttpResponse::Ok().body(response.text().await.unwrap_or_default())
}

This approach removes user input from the request target, eliminating SSRF. The Bearer Token is still used, but only for a trusted internal endpoint.

Secure Example: Whitelisted Host with Conditional Token Usage

use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use reqwest::Client;
use url::Url;

async fn controlled_proxy(query: web::Query impl Responder {
    let base = query.get("path").map(|p| p.as_str()).unwrap_or("/");
    let parsed = Url::parse(&format!("https://api.example.com/{}", base)).ok()?;

    // Strict host allowlist
    if parsed.host_str() != Some("api.example.com") {
        return HttpResponse::BadRequest().body("invalid host");
    }

    let token = "my-secret-bearer-token";
    let client = Client::builder()
        .redirect(reqwest::redirect::Policy::none())
        .build()
        .unwrap();

    let response = client
        .get(parsed.as_str())
        .bearer_auth(token)
        .send()
        .await
        .unwrap_or_else(|_| HttpResponse::BadGateway().finish());

    HttpResponse::Ok().body(response.text().await.unwrap_or_default())
}

This example validates the host against an allowlist and disables redirects to prevent SSRF pivoting. The Bearer Token is only used for the approved domain. For production, consider rotating tokens and using short-lived credentials to reduce exposure if a vulnerability is present.

middleBrick can help verify these controls by scanning your Actix API’s OpenAPI spec and runtime behavior. It checks whether authentication headers are exposed to untrusted endpoints and flags missing host allowlists or redirect handling. The CLI tool (middlebrick scan <url>) and GitHub Action make it easy to integrate these checks into development workflows.