Fix XSS in API Responses in Actix Web

APIs are often overlooked in XSS audits, but they are prime targets. If an Actix Web endpoint reflects user-controlled input without a strict Content-Type or proper encoding, a browser may 'sniff' the response as HTML and execute malicious scripts. The goal is to enforce a strict data-only context and prevent the browser from interpreting the response body as executable code.

The Vulnerable Pattern

use actix_web::{get, web, HttpResponse, Responder};
#[get(“/echo/{data}”)]
async fn vulnerable_handler(data: web::Path) -> impl Responder {
// VULNERABLE: Reflects input directly into the body.
// If a user visits /echo/, the browser might
// execute the script if it misinterprets the content type.
HttpResponse::Ok().body(data.into_inner())
}

The Secure Implementation

To neutralize XSS in Actix Web APIs, follow three rules: 1. Use the .json() responder to explicitly set the 'Content-Type' to 'application/json'. 2. Implement 'X-Content-Type-Options: nosniff' as middleware to prevent browsers from bypassing the declared content type through MIME-sniffing. 3. Ensure your API responses are properly encoded; by using Serde with .json(), data is structured in a format that browsers will not parse as HTML elements even if they contain angle brackets.

use actix_web::{get, web, HttpResponse, Responder};
use serde::Serialize;
#[derive(Serialize)]
struct ApiResponse {
message: String,
}
#[get(“/echo/{data}”)]
async fn secure_handler(data: web::Path) -> impl Responder {
// SECURE: Use .json() to force ‘application/json’ Content-Type.
// This prevents browsers from interpreting the response as HTML.
HttpResponse::Ok().json(ApiResponse {
message: data.into_inner(),
})
}