Cross-site scripting (XSS) in an Axum application protected by mutual TLS (mTLS) can occur when server-side rendering or HTML serialization does not escape user-controlled data, even though mTLS provides strong client authentication. mTLS ensures that only authenticated clients with valid certificates can reach your Axum endpoints, but it does not prevent an authenticated client from submitting malicious payloads that get reflected in HTML responses. For example, an API handler that accepts a query parameter or JSON body and embeds it directly into an HTML template without escaping can lead to reflected XSS. An attacker who has obtained a client certificate (e.g., via compromise or provisioning abuse) can craft requests that inject scripts into the response seen by the certificate holder or other parties if the application shares responses across users.

Consider an Axum handler that returns a greeting using raw user input:

use axum::{routing::get, Router};
use std::net::SocketAddr;

async fn hello(name: String) -> String {
    format!("
Hello, {}
", name)
}

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

If an authenticated client with a valid mTLS certificate sends name as <script>steal()</script>, the HTML response will execute the script in the victim’s browser. mTLS does not mitigate this because the TLS layer terminates before the application processes the payload; XSS is an application-layer issue. The risk is compounded if the application embeds user input into JavaScript contexts or uses dangerous innerHTML-like patterns in frontend templates served by Axum. XSS can lead to session hijacking, credential theft, or unauthorized actions on behalf of the authenticated client.

To align with the scanner’s checks, remember that middleBrick tests input validation and data exposure to detect such injection issues, even when mTLS is in place. The scanner does not assume mTLS eliminates XSS; it flags missing output encoding regardless of transport security.

Remediation focuses on context-aware output encoding and strict input validation. For HTML body content, use an escaping library appropriate for the template engine. If you render HTML directly in handlers, escape special characters before insertion. Below is an Axum handler using the askama type-safe template engine, which auto-escapes variables by default:

<!-- templates/hello.html -->
<h1>Hello, {{ name }}</h1>

use axum::{routing::get, Router};
use askama::Template;
use std::net::SocketAddr;

#[derive(Template)]
#[template(path = "hello.html")]
struct HelloTemplate {
    name: String,
}

async fn hello(name: String) -> HelloTemplate {
    HelloTemplate { name }
}

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

If you build HTML strings manually, apply percent-encoding or HTML-entity encoding. For JavaScript contexts, use JSON serialization with proper content-type headers. Here is an Axum handler that encodes user input for HTML body context using the html_escape crate:

use axum::{routing::get, Json, Router};
use html_escape::{encode_text};
use serde::Deserialize;
use std::net::SocketAddr;

#[derive(Deserialize)]
struct NameInput {
    name: String,
}

async fn hello_json(Json(payload): Json) -> String {
    let safe_name = encode_text(&payload.name);
    format!("
Hello, {}
", safe_name)
}

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

For mTLS-enabled Axum services, continue to enforce client certificate validation at the transport layer, but do not rely on it for output safety. Combine mTLS with strict input validation rules (e.g., allowlist patterns for names) and context-sensitive escaping. middleBrick’s scans include checks for improper encoding and will flag endpoints that reflect user input without escaping, regardless of mTLS presence.