Ssrf in Actix with Cockroachdb

Server-Side Request Forgery (SSRF) in an Actix web service that uses CockroachDB can occur when an Actix endpoint accepts a URL or host input and uses it to make an outbound HTTP request or to form a database connection string. If the application does not validate or restrict the destination, an attacker can direct the server to interact with internal services, including the CockroachDB node(s) that your application connects to.

In a typical Actix setup, developers may build a proxy or integration helper that fetches resources on behalf of clients. If the target URL is taken directly from user input and passed to an HTTP client without allowlisting, the server can be tricked into making requests to internal endpoints. Because CockroachDB often exposes an HTTP admin UI (on port 8080 by default) and gossip or SQL traffic can be reachable from the application host, an SSRF flaw can become a pivot point to enumerate or abuse the database layer without direct network access.

With OpenAPI/Swagger analysis, middleBrick correlates runtime behavior with your spec: if an endpoint declares that it retrieves a "resource URL" from the caller and then performs an HTTP call, and the spec does not explicitly restrict the schema to external, public domains, the scan flags this as an SSRF-related finding. Even without credentials, middleBrick’s unauthenticated attack surface tests can trigger SSRF indicators by observing whether the endpoint causes outbound requests to internal IPs or to the CockroachDB admin interface.

For example, consider an Actix route that accepts a URL parameter to fetch a remote configuration. If the route does not validate the host, an attacker can supply http://localhost:8080/_status/vars to reach CockroachDB’s debug endpoints, or use internal metadata services (169.254.169.254) to learn about the environment. The security risk is not only data exposure but also potential lateral movement: from SSRF, an attacker may probe internal services, including CockroachDB’s SQL port via a local proxy, especially when the database is not bound to external interfaces but the application container shares the network stack.

middleBrick flags this combination as high risk because it demonstrates that unauthenticated endpoints in Actix can inadvertently expose database-adjacent surfaces. The scanner’s 12 security checks run in parallel, with the SSRF check correlating findings from input validation and property authorization tests to highlight whether user-supplied input can traverse to backend data stores.

Remediation focuses on strict input validation, network controls, and avoiding the use of user input in outbound requests or connection strings. For Actix routes that handle URLs or host parameters, implement allowlisting, reject private IP ranges, and avoid forwarding requests to localhost or internal addresses. For database interactions, ensure connection strings do not incorporate dynamic user input.

Example of a vulnerable Actix handler that accepts a URL and uses reqwest to fetch it:

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

// Vulnerable: user_url can point to any host, including CockroachDB admin endpoints
async fn fetch_resource(user_url: web::Query<HashMap<String, String>>) -> Result<HttpResponse> {
    let client = Client::new();
    let url = user_url.get("url").ok_or_else(|| actix_web::error::ErrorBadRequest("missing url"))?;
    let resp = client.get(url).send().await?;
    let body = resp.text().await?;
    Ok(HttpResponse::Ok().body(body))
}

Secure rewrite with host validation and no internal resolution:

use actix_web::{web, HttpResponse, Result};
use reqwest::Client;
use std::net::IpAddr;

// Allowed domains: only example.com and assets.example.com
const ALLOWED_DOMAINS: [&str; 2] = ["example.com", "assets.example.com"];

fn is_allowed_host(url: &str) -> bool {
    if let Ok(parsed) = url::Url::parse(url) {
        if let Some(host) = parsed.host_str() {
            if ALLOWED_DOMAINS.contains(&host) {
                return true;
            }
            // Reject localhost and private IPs
            if host == "localhost" {
                return false;
            }
            if let Ok(ip) = host.parse::() {
                return !ip.is_loopback() && !ip.is_private();
            }
        }
    }
    false
}

async fn fetch_resource_safe(user_url: web::Query<HashMap<String, String>>) -> Result<HttpResponse> {
    let client = Client::new();
    let url = user_url.get("url").ok_or_else(|| actix_web::error::ErrorBadRequest("missing url"))?;
    if !is_allowed_host(url) {
        return Ok(HttpResponse::Forbidden().body("host not allowed"));
    }
    let resp = client.get(url).send().await?;
    let body = resp.text().await?;
    Ok(HttpResponse::Ok().body(body))
}

For Cockroachdb connections, do not construct connection strings from user input. Use static configuration or environment variables with strict network policies:

use actix_web::web;
use cockroach_client::CockroachDb;

// Safe: connection details are fixed and not derived from user input
async fn get_db_client() -> CockroachDb {
    let connection_string = std::env::var("COCKROACH_CONNECTION_STRING")
        .unwrap_or_else(|_| "postgresql://root@localhost:26257/defaultdb?sslmode=disable".into());
    CockroachDb::new(connection_string).expect("valid connection string")
}

Additionally, ensure that the Actix runtime does not expose administrative endpoints to the public internet and that CockroachDB is bound only to trusted interfaces. middleBrick’s Pro plan supports continuous monitoring so that changes to endpoints or dependencies do not reintroduce SSRF risks; you can add API security checks to your CI/CD pipeline to fail builds if risk scores exceed your threshold.