Nosql Injection in Actix with Jwt Tokens

When an Actix web service parses a JSON Web Token (JWT) and uses claims to build NoSQL queries, a combination of authentication logic and query construction can expose injection risks. JWTs commonly carry user identifiers, roles, or tenant IDs in payload claims. If those claims are directly interpolated into a NoSQL query string or used to construct dynamic filters without validation, an attacker who can influence the token—via a stolen token, a weak issuer validation, or a vulnerable public-key recovery path—can manipulate query behavior.

For example, consider an Actix handler that extracts a sub claim and uses it to filter documents in a MongoDB collection. If the handler does not treat the claim as untrusted input, a malicious actor could present a modified JWT with a crafted sub value such as "$ne": "" or a JSON-like string that alters the semantics of the resulting query. In a typical NoSQL injection scenario, this could lead to authentication bypass (reading other users’ data) or data exfiltration. The risk is compounded when the JWT is accepted without strict signature verification or when the Actix service trusts the payload beyond basic expiry and issuer checks.

Even when using a robust JWT validation library, the developer must still sanitize and parameterize any data derived from the token before using it in a NoSQL query. The Actix framework itself does not introduce injection, but the way claims are consumed does. Common patterns include building a filter object by directly assigning claim values, concatenating strings to form query conditions, or passing raw claim values into database driver methods that accept JSON-like structures. Without explicit allow-lists, type checks, and strict schema validation, these patterns create a path for injection-like manipulation in the database layer.

Real-world attack patterns mirror those seen in OWASP API Top 10’s Broken Object Level Authorization (BOLA) and Injection categories. A compromised JWT with elevated roles might be used in tandem with tainted claim values to escalate permissions or traverse tenant boundaries. For instance, if an Actix service constructs a query like { "tenant_id": "{tenant}", "roles": { "$in": "{roles}" } } by inserting claim values as raw JSON fragments, an attacker could supply a role claim containing operators such as { "$ne": null }, potentially exposing records that should be restricted.

Because middleBrick scans the unauthenticated attack surface and tests inputs that reach the API—including tokens presented at the gateway—it can detect endpoints where JWT-derived data reaches NoSQL queries without adequate sanitization. Findings will highlight missing input validation, missing parameterization, and missing schema enforcement, with remediation guidance mapped to relevant compliance frameworks such as OWASP API Security Top 10 and general injection best practices.

Remediation focuses on treating JWT claims as untrusted input and ensuring all data derived from them is validated, constrained, and parameterized before being used in NoSQL queries. In Actix, this means validating the token with a trusted library, enforcing strict claim schemas, and constructing query filters using safe structures rather than string interpolation.

First, verify the JWT using a well-maintained crate such as jsonwebtoken, and enforce issuer, audience, expiry, and signature validation. Do not rely on manual parsing of the payload. After validation, deserialize claims into a strongly typed struct and apply allow-list validation on any fields used for querying.

Second, avoid building query filters by concatenating JSON fragments. Instead, build explicit filter objects and bind values as parameters. For MongoDB, prefer the typed builder APIs or construct filter documents using the official crate’s document macros, ensuring that user-controlled values are placed in values, not in keys or operators.

Third, apply principle of least privilege to the database credentials used by the Actix service. Even with proper validation, limiting the operations the service account can perform reduces the impact of a potential misconfiguration.

Example: secure token validation and query building in Actix using jsonwebtoken and the official MongoDB Rust driver:

use actix_web::{web, HttpResponse, Result};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use serde::{Deserialize, Serialize};
use mongodb::{bson::{doc, Document}, options::ClientOptions, Client};

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    roles: Vec<String>,
    tenant_id: String,
    exp: usize,
    iss: String,
}

async fn get_user_data(
    token: String,
    db_client: web::Data<Client>,
) -> Result<HttpResponse> {
    let validation = Validation::new(Algorithm::HS256);
    let token_data = decode<Claims>(
        &token,
        &DecodingKey::from_secret("YOUR_STRONG_SECRET".as_ref()),
        &validation,
    ).map_err(|_| HttpResponse::Unauthorized().finish())?;

    let claims = token_data.claims;

    // Validate claim values against an allow-list before using them in a query.
    let allowed_tenants = ["tenant_a", "tenant_b"];
    if !allowed_tenants.contains(&claims.tenant_id.as_str()) {
        return Err(HttpResponse::Forbidden().finish());
    }

    let roles_allowlist = ["admin", "viewer"];
    for role in &claims.roles {
        if !roles_allowlist.contains(&role.as_str()) {
            return Err(HttpResponse::Forbidden().finish());
        }
    }

    let db = db_client.database("app_db");
    // Build filter using safe document construction; values are bound, not concatenated.
    let filter = doc! {
        "tenant_id": claims.tenant_id,
        "roles": doc! { "$in": claims.roles },
    };

    let collection = db.collection("users");
    match collection.find_one(filter, None).await {
        Ok(Some(doc)) => Ok(HttpResponse::Ok().json(doc)),
        Ok(None) => Ok(HttpResponse::NotFound().finish()),
        Err(e) => Ok(HttpResponse::InternalServerError().body(e.to_string())),
    }
}

For JWTs presented in headers, ensure the Actix middleware validates the token before reaching the handler and strips the raw token from any downstream logging to reduce accidental exposure. Combine this with input validation at the handler level and parameterized query construction to mitigate injection paths tied to JWT-derived data.