Webhook Spoofing in Axum (Rust)

Webhook spoofing occurs when an attacker can cause an application to deliver webhook events to an endpoint they control. In Axum with Rust, this risk arises when a handler accepts incoming requests that influence which external callback URL is invoked without strict validation of the target origin. Axum is an ergonomic web framework built on Tower and Hyper, and it does not enforce any out-of-the-box restrictions on user-supplied URLs. If a route accepts a parameter such as webhook_url or uses a header like X-Webhook-URL to decide where to forward events, an attacker can supply a malicious endpoint and capture sensitive data or trigger unintended workflows.

Because Axum handlers are asynchronous and often composed with middleware such as headers and body extractors, spoofing can be introduced at multiple layers. For example, a handler that deserializes a JSON payload containing a callback URL and then performs an outbound HTTP request without verifying the domain allows spoofing. Attack patterns include redirecting webhook notifications to a server under the attacker’s control or exploiting open redirects in combination with trust mechanisms that rely on hostname or scheme alone. Even when Axum routes are well-structured, the surrounding infrastructure (load balancers, proxies) can alter headers in ways that make spoofed origins appear legitimate if the application does not independently validate the intended destination.

In the context of API security scanning, webhook spoofing is surfaced when a scanner observes that user-controlled data flows into network call location decisions. Such findings often map to the broader OWASP API Top 10 categories like Broken Object Level Authorization and Security Misconfiguration. The risk is especially pronounced when combined with other weaknesses, such as insufficient input validation or missing authentication on outbound requests. Because Axum does not provide a built-in webhook registry or destination verification, developers must explicitly enforce allowlists, validate hostnames, and reject unexpected schemes to reduce the attack surface.

To prevent webhook spoofing in Axum, validate and constrain any user-influenced destination before using it in outbound requests. Prefer configuration-driven allowlists over dynamic URLs, and when dynamic URLs are necessary, enforce strict hostname and scheme checks. The following patterns demonstrate safe approaches using Rust types and Axum extractors.

1. Validate with a hardcoded allowlist

When the set of acceptable webhook targets is known at compile time, store them as static values and compare the incoming request’s target against this allowlist. This eliminates runtime ambiguity and prevents redirection to attacker-controlled domains.

use axum::{routing::post, Router};
use serde::Deserialize;
use reqwest::Client;
use std::net::SocketAddr;

#[derive(Deserialize)]
struct Event {
    target: String,
    // other fields...
}

async fn handle_event(
    event: Event,
    client: &Client,
) -> Result<(), (axum::http::StatusCode, String)> {
    const ALLOWED_WEBHOOKS: &[&str] = &[
        "https://api.example.com/webhooks/alerts",
        "https://api.partner.com/notify",
    ];

    if !ALLOWED_WEBHOOKS.contains(|&url| url == event.target) {
        return Err((axum::http::StatusCode::BAD_REQUEST, "invalid webhook target".into()));
    }

    client.post(&event.target)
        .json(&event)
        .send()
        .await
        .map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    Ok(())
}

#[tokio::main]
async fn main() {
    let app = Router::new().route("/events", post(handle_event));
    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

2. Parse and validate dynamic URLs with url and public_suffix

When URLs must be supplied at runtime, parse them to inspect the host and scheme. Use the url crate to construct a Url and public_suffix (or trust-dns-resolver for more advanced checks) to ensure the host is within an approved domain. Reject URLs with non-HTTP(S) schemes, IP addresses, or private ranges unless explicitly allowed.

use axum::routing::post;
use serde::Deserialize;
use url::Url;

async fn handle_dynamic_webhook(
    body: String,
) -> Result {
    #[derive(Deserialize)]
    struct Payload {
        webhook_url: String,
        data: String,
    }

    let payload: Payload = serde_json::from_str(&body)
        .map_err(|_| (axum::http::StatusCode::BAD_REQUEST, "invalid JSON".into()))?;

    let parsed = Url::parse(&payload.webhook_url)
        .map_err(|_| (axum::http::StatusCode::BAD_REQUEST, "invalid URL".into()))?;

    if parsed.scheme() != "https" {
        return Err((axum::http::StatusCode::BAD_REQUEST, "only HTTPS allowed".into()));
    }

    let host = parsed.host_str()
        .ok_or_else(|| (axum::http::StatusCode::BAD_REQUEST, "missing host".into()))?;

    // Example allowlist check; in production, use a robust policy (e.g., public suffix + domain)
    if host.ends_with("example.com") {
        // proceed with outbound request to parsed.url()
        Ok(format("accepted: {}", host))
    } else {
        Err((axum::http::StatusCode::FORBIDDEN, "host not allowed".into()))
    }
}

#[tokio::main]
async fn main() {
    let app = Router::new().route("/webhook", post(handle_dynamic_webhook));
    // bind and serve omitted for brevity
}

These patterns emphasize explicit control over destinations. For broader API security coverage, including automated scans that detect webhook spoofing and related misconfigurations, teams using the middleBrick CLI can integrate middlebrick scan <url> into development workflows, while the GitHub Action can enforce score thresholds in CI/CD pipelines to prevent insecure routing logic from reaching production.