Ssrf in Actix with Basic Auth

Server-Side Request Forgery (SSRF) in Actix applications that also use HTTP Basic Authentication can expose internal services and bypass network-level access controls. In this combination, an attacker may leverage SSRF to make the server perform authenticated requests to internal endpoints that are not exposed to the public internet.

Actix web applications often make outbound HTTP requests—for example, to call downstream APIs or legacy services. If user-supplied input is used to construct those requests without strict validation, an attacker can supply a URL that points to an internal address such as http://127.0.0.1:8080/admin or a cloud metadata service like http://169.254.169.254/latest/meta-data/. When the backend uses Basic Authentication, the credentials are typically embedded in the request headers or via a default client configured with credentials. An SSRF payload can cause the server to forward those credentials to internal endpoints that would otherwise be unreachable, effectively bypassing network segmentation.

For example, consider an Actix service that accepts a URL parameter to proxy a request and attaches Basic Authentication headers to every outgoing call. An attacker could provide http://admin:secret@127.0.0.1:8080/internal, or more realistically abuse open redirector patterns or header injection to inject credentials into an internal request. Even without direct parameter injection, SSRF can be chained with internal DNS or cloud instance metadata to reach services that expect authentication via Basic Auth headers. The risk is compounded when the internal service trusts the source IP or relies on the presence of Authorization headers to enforce access control.

Using middleBrick, such SSRF issues are detected as part of the SSRF and Input Validation checks, which analyze endpoint behavior without authentication (black-box scanning). The scanner tests whether user-supplied inputs can influence outbound requests and whether sensitive data or internal network interactions are observable. Findings include severity ratings and remediation guidance mapped to frameworks such as OWASP API Top 10 and helps teams understand the exposure without assuming automatic remediation.

Remediation focuses on strict input validation, avoiding the use of user-controlled data in outbound request targets, and ensuring credentials are not embedded in requests that can be influenced by an attacker. Do not construct URLs from user input, and do not forward Authorization headers derived from user input to downstream services.

Below are concrete Actix examples showing a vulnerable pattern and a secure alternative.

Vulnerable Actix handler using Basic Auth and user-supplied URL

use actix_web::{web, HttpResponse, Responder};
use reqwest::Client;
use std::collections::HashMap;

// WARNING: This pattern is vulnerable to SSRF and credential leakage.
async fn proxy_request(params: web::Query>) -> impl Responder {
    let target_url = params.get("url").unwrap_or(&"http://default.service/api".to_string());
    let username = "admin";
    let password = "secret";

    let client = Client::new();
    let response = client
        .get(target_url)
        .basic_auth(username, Some(password))
        .send()
        .await;

    match response {
        Ok(resp) => HttpResponse::Ok().body(resp.text().await.unwrap_or_default()),
        Err(_) => HttpResponse::BadGateway().finish(),
    }
}

Issues: The target_url is taken directly from user input. An attacker can supply an internal URL, and Basic Auth credentials are always attached, potentially leaking credentials to internal services.

Secure Actix handler with strict allowlist and no dynamic auth

use actix_web::{web, HttpResponse, Responder};
use reqwest::Client;
use std::collections::HashMap;

// Secure pattern: allowlist known endpoints, do not forward Basic Auth from user input.
async fn safe_proxy_request(params: web::Query>) -> impl Responder {
    let allowed_hosts = ["api.service.example.com", "internal.service.corp"];
    let target_path = params.get("resource").map(|s| s.as_str()).unwrap_or("/data");

    // Validate resource against an allowlist; do not construct full URLs from user input.
    let host = match params.get("host").map(|s| s.as_str()) {
        Some(h) if allowed_hosts.contains(&h) => h,
        _ => return HttpResponse::BadRequest().body("host not allowed"),
    };

    let full_url = format!("https://{}/{}", host, target_path.trim_start_matches('/'));
    let client = Client::new();

    // Do not use Basic Auth derived from user input; use a securely managed credential.
    // For example, read from environment or a secure vault at startup.
    let app_username = std::env::var("APP_USER").unwrap_or_else(|_| "appuser".to_string());
    let app_password = std::env::var("APP_PASS").unwrap_or_else(|_| "appsecret".to_string());

    let response = client
        .get(&full_url)
        .basic_auth(&app_username, Some(&app_password))
        .send()
        .await;

    match response {
        Ok(resp) => HttpResponse::Ok().body(resp.text().await.unwrap_or_default()),
        Err(_) => HttpResponse::BadGateway().finish(),
    }
}

Key mitigations:

• Do not accept arbitrary URLs from clients; use an allowlist for hosts and a restricted set of resources.
• Do not construct outbound request URLs by concatenating user input without strict validation.
• Avoid forwarding Authorization headers that were derived from user input; use application-level credentials stored securely and referenced via environment variables or a secrets manager.
• Limit outbound network access at the runtime environment (container network policies) so that the service can only reach known internal endpoints, reducing the impact of any potential SSRF.

These practices reduce the risk of SSRF being used to pivot to internal services that rely on Basic Authentication, and they align with secure coding guidance for HTTP client usage in Actix-based services.