Xss Cross Site Scripting in Actix with Jwt Tokens

Cross-site scripting (XSS) in Actix applications that rely on JWT tokens can occur when an application reflects untrusted data into HTML, XML, or JavaScript contexts without proper encoding or validation. JWT tokens themselves are not inherently unsafe, but if a server embeds token metadata or claims (e.g., user name, roles, or custom fields) into a rendered response without escaping, an attacker can inject malicious scripts that execute in the victim’s browser.

In Actix web applications, routes often deserialize JWT tokens to extract claims, then use those claims to personalize responses. If a developer directly includes claims in HTML templates or JSON responses that are interpreted as HTML by the browser, and the claims contain user-controlled input (e.g., from token payload or from parameters influenced by the token), this creates an injection vector. For example, a token containing a name like <script>alert(1)</script> that is rendered unescaped into the page can lead to stored or reflected XSS. Additionally, if an API endpoint returns JSON that includes token-derived fields and the client-side JavaScript evaluates or inserts those fields into the DOM unsafely, the token’s data can facilitate script execution.

This combination is notable because JWTs are commonly used for stateless authentication, and developers may assume that server-side token validation is sufficient. However, validation does not prevent the application from reflecting unsafe data derived from the token. XSS can bypass the same-origin policy, steal session tokens, perform actions on behalf of the user, or manipulate page behavior. The risk is especially pronounced when token claims are used in error messages, debug endpoints, or dynamic HTML fragments that are not contextually encoded.

Real-world attack patterns include tricking a user into visiting a crafted link that includes a malicious payload in a query parameter, which is then validated via a JWT and reflected in the response. In single-page applications, improperly sanitized token claims inserted via innerHTML or document.write provide another common path. While the JWT ensures the request is authenticated, the server must still treat all data extracted from or influenced by the token as untrusted in output contexts.

Remediation focuses on context-aware output encoding, strict validation of token claims, and avoiding direct reflection of untrusted data. Below are concrete Actix examples demonstrating secure handling of JWT-derived data.

1. Validate and sanitize claims before use. Do not trust the payload beyond signature verification. Use a strict schema to extract only expected fields and encode values for the target context (HTML, attribute, JavaScript).

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

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    name: String,
    role: String,
    // Do not include arbitrary or untrusted fields
}

fn validate_token(token: &str) -> Result {
    let decoding_key = DecodingKey::from_secret("your-secret".as_ref());
    let mut validation = Validation::new(Algorithm::HS256);
    validation.validate_exp = true;
    let token_data = decode::(token, &decoding_key, &validation)?;
    // Apply allow-list: only accept expected claims
    Ok(Claims {
        sub: token_data.claims.sub,
        name: token_data.claims.name,
        role: token_data.claims.role,
    })
}

async fn profile(token: web::Query) -> impl Responder {
    match validate_token(&token.token) {
        Ok(claims) => {
            // Encode for HTML context before embedding
            let safe_name = html_escape::encode_text(&claims.name);
            HttpResponse::Ok().body(format!("
Name: {}
", safe_name))
        }
        Err(_) => HttpResponse::Unauthorized().body("Invalid token"),
    }
}

2. Use type-safe template rendering with automatic escaping. Actix-web integrates with Askama or Tera, which escape variables by default when configured properly.

// With Askama, define a template:
// templates/profile.html: <div>Name: {{ name }}</div>
#[derive(Template)]
#[template(path = "profile.html")]
struct ProfileTemplate {
    name: String,
}

async fn profile_askama(claims: web::Json) -> impl Responder {
    let template = ProfileTemplate {
        name: claims.name.clone(), // Askama escapes HTML by default
    };
    HttpResponse::Ok().content_type("text/html").body(template.render().unwrap_or_default())
}

3. For JSON responses, ensure content-type is correct and avoid inserting raw HTML. If the client will render data, encode for the specific context (e.g., JS string encoding) and enforce strict Content-Type headers.

async fn api_profile(claims: web::Json) -> impl Responder {
    // Return safe JSON; do not embed in HTML
    HttpResponse::Ok()
        .content_type("application/json")
        .json(serde_json::json!({
            "name": claims.name,
            "role": claims.role,
        }))
}

4. Harden token handling: set short expiration times, use HTTPS, and validate standard claims (iss, aud) to reduce the impact of token leakage. Avoid placing sensitive or high-risk data in the token payload if it will be reflected anywhere.