Ssrf Server Side in Actix with Api Keys

Server Side Request Forgery (SSRF) in Actix applications that rely on API keys for outbound calls occurs when an attacker can coerce the server into making arbitrary requests from the server-side context, often using the trusted API key to reach internal or restricted endpoints. Because the API key is typically sourced from configuration or an environment variable and used in outbound HTTP calls, SSRF can abuse that trusted identity to bypass network-level restrictions, access cloud metadata services, or interact with internal services that are not exposed publicly.

In an Actix web service, this commonly arises when an endpoint accepts a URL from a client and forwards it with an API key, without strict validation of the destination. For example, a backend proxy or integration handler might build a request using a hardcoded or configured API key and then use the provided URL as the target. If the attacker supplies an internal address such as http://169.254.169.254 (AWS metadata) or a Kubernetes internal endpoint, the server-side request will include the API key and may succeed where direct client access would be blocked. The SSRF vulnerability here is not about the API key being exposed; it is about the server using a powerful outbound credential to make attacker-controlled network calls, which can lead to data exfiltration, SSRF-to-EC2/metadata exploits, or pivoting into internal networks.

middleBrick detects SSRF as part of its standard 12 security checks, including a specific SSRF category, and this is relevant whether or not API keys are in use. When API keys are involved, the findings often carry higher severity because a compromised server can leverage trusted credentials to reach sensitive internal resources. The scanner exercises unauthenticated attack surfaces and, where spec and runtime data are available, cross-references OpenAPI/Swagger definitions (including $ref resolution) to identify endpoints that accept external URLs and inspect outbound patterns. For LLM-specific contexts, middleBrick also checks for unsafe consumption patterns where generated code or prompts might inadvertently introduce SSRF in API-consuming logic.

Remediation focuses on preventing untrusted input from influencing outbound destinations and reducing the scope of API keys. Do not forward client-supplied URLs directly. Instead, use allowlists, strict URL parsing, and restricted network targets. Ensure API keys are not automatically used for every outbound call without validating the target.

Example of vulnerable Actix code that forwards a user-supplied URL and uses an API key:

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

async fn proxy_endpoint(web::Query(params): web::Query>) -> impl Responder {
    let api_key = std::env::var("OUTBOUND_API_KEY").unwrap_or_default();
    let target_url = params.get("url").cloned().unwrap_or_default();
    let client = Client::new();
    let res = client
        .get(&target_url)
        .bearer_auth(api_key)
        .send()
        .await;
    match res {
        Ok(resp) => HttpResponse::Ok().body(resp.text().await.unwrap_or_default()),
        Err(_) => HttpResponse::BadGateway().finish(),
    }
}

This pattern is risky because target_url is user-controlled and the trusted API key is applied to it. An attacker can point the request to internal services or metadata endpoints.

Secure alternative using an allowlist and no API key for internal targets:

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

async fn proxy_endpoint_safe(web::Query(params): web::Query>) -> impl Responder {
    let api_key = std::env::var("OUTBOUND_API_KEY").unwrap_or_default();
    let target_url = params.get("url").cloned().unwrap_or_default();
    let base = Url::parse("https://api.external-service.com").expect("valid base");
    let parsed = match Url::parse(&target_url) {
        Ok(u) => u,
        Err(_) => return HttpResponse::BadRequest().body("Invalid URL"),
    };
    // Allowlist check: ensure the host matches expected external service
    if parsed.host_str() != Some("api.external-service.com") {
        return HttpResponse::Forbidden().body("Destination not allowed");
    }
    // Optionally enforce path prefix rules here
    let client = Client::new();
    let res = client
        .get(parsed)
        .bearer_auth(api_key)
        .send()
        .await;
    match res {
        Ok(resp) => HttpResponse::Ok().body(resp.text().await.unwrap_or_default()),
        Err(_) => HttpResponse::BadGateway().finish(),
    }
}

Key points:

• Validate and parse the URL before use; reject non-HTTP(S) schemes and malformed URLs.
• Enforce a strict host allowlist so the API key is only used for the intended external service.
• Consider not attaching API keys to requests that are not strictly necessary, or scope keys with IP restrictions and minimal permissions.
• For integrations that must accept arbitrary endpoints (e.g., webhook relays), avoid using powerful credentials and instead use scoped tokens with network-level restrictions.

middleBrick’s CLI can validate your endpoints and scans can be integrated into your workflow; for example, use the CLI to scan from terminal with middlebrick scan <url>, or add API security checks to your CI/CD pipeline with the GitHub Action to fail builds if risk scores drop below your chosen threshold.