Ssrf Server Side in Actix with Jwt Tokens

Server Side Request Forgery (SSRF) in Actix applications that rely on JWT tokens for authorization can occur when an endpoint that validates or forwards requests also makes outbound HTTP calls using data supplied by the caller. If the API accepts a URL or host header and uses it to call another service while trusting the JWT identity of the request, an attacker can direct those outbound calls to internal or restricted targets.

For example, an endpoint may accept a JWT in the Authorization header, parse the subject or roles, and then initiate an HTTP request to a user-supplied URL to fetch external data or proxy through an internal service. Because the server-side request is made from a trusted runtime, it may bypass egress firewall rules and access metadata services, internal APIs, or cloud instance metadata endpoints. The presence of JWT tokens can create a false sense of security: the API trusts the caller’s identity but does not sufficiently validate or restrict the destination of the outbound request, allowing an authenticated context to be abused for SSRF.

In Actix, this can surface when handlers use clients like reqwest or actix-web’s HttpClient to fetch from a URL constructed from request parameters. If the handler does not enforce strict allowlists on hosts and schemes, and if it runs in the same process as the token validation logic, an authenticated request can trigger SSRF that reaches internal services not exposed to the public internet. The risk is compounded when the API also exposes introspection or metadata endpoints that return sensitive information to callers that present a valid token.

Remediation focuses on strict destination validation, removing user-controlled URLs from outbound paths, and ensuring JWT usage does not inadvertently authorize unsafe network calls. Use allowlisted hosts and ports, avoid forwarding user-supplied URLs, and treat tokens as authorization signals rather than network routing controls.

Example: Unsafe handler with user-supplied URL

use actix_web::{web, HttpResponse, Responder};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};

async fn fetch_url(params: web::Query, req: actix_web::HttpRequest) -> impl Responder {
    let token = params.token.as_ref().ok_or("missing token")?;
    let decoded = decode::(
        token,
        &DecodingKey::from_secret("secret".as_ref()),
        &Validation::new(Algorithm::HS256),
    )?;
    // Unsafe: uses attacker-controlled URL
    let url = params.url.clone();
    let client = reqwest::Client::new();
    let resp = client.get(&url).send().await?;
    HttpResponse::Ok().body(resp.text().await?)
}

Fixed handler: allowlisted destinations and token-bound routing

use actix_web::{web, HttpResponse, Responder};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use url::Url;

async fn safe_fetch(params: web::Query, req: actix_web::HttpRequest) -> impl Responder {
    let token = params.token.as_ref().ok_or("missing token")?;
    let decoded = decode::(
        token,
        &DecodingKey::from_secret("secret".as_ref()),
        &Validation::new(Algorithm::HS256),
    )?;
    // Validate destination against an allowlist
    let parsed = Url::parse(¶ms.url).map_err(|_| "invalid url")?;
    if !["api.internal.corp", "data.service.example.com"].contains(&parsed.host_str().unwrap_or("")) {
        return HttpResponse::BadRequest().body("destination not allowed");
    }
    if parsed.scheme() != "https" {
        return HttpResponse::BadRequest().body("only https allowed");
    }
    let client = reqwest::Client::new();
    let resp = client.get(parsed.as_str())
        .header("X-Subject", decoded.claims.sub)
        .send().await?;
    HttpResponse::Ok().body(resp.text().await?)
}

#[derive(serde::Deserialize)]
struct SafeParams {
    token: String,
    url: String,
}

Additional measures include using a service mesh or outbound proxy to enforce egress policies, disabling outbound connections to metadata endpoints from application containers, and logging outbound destination attempts tied to JWT subject identifiers for audit. These steps reduce the window for SSRF while preserving the utility of JWT-based access control.