Sql Injection in Actix with Jwt Tokens

SQL injection in Actix applications that rely on JWT tokens for authentication can occur when developers use decoded token claims to construct dynamic SQL queries without proper safeguards. Even though JWTs themselves are cryptographically signed and tamper-evident, the data they carry (claims) must still be treated as untrusted input. In Actix, handlers often extract a subject or role claim from a JWT and directly interpolate those values into SQL strings, for example building a query like format!("SELECT * FROM users WHERE id = '{}'", user_id). This pattern is dangerous because if the token is issued by an external system or if the application trusts the decoded payload without validation, an attacker who can influence the token’s claims (through a compromised signing key, algorithm confusion, or a malicious token) can inject SQL payloads that are later executed against the database.

The risk is compounded when JWTs are used to bypass weaker authorization checks. For instance, a developer might assume that a JWT role claim reliably indicates admin status and then build queries with elevated privileges. If the role claim is forged or the validation logic is misconfigured, an attacker can supply crafted SQL fragments via claims such as username or tenant_id, leading to unauthorized data access or modification. The SQL injection surface is not in the token verification step itself, but in how the application uses claims after verification to interact with the database. Therefore, even when JWTs are properly verified, constructing queries by concatenating claims remains a critical vulnerability that maps to the OWASP API Top 10 and commonly surfaces in scans as BOLA/IDOR and Input Validation findings.

middleBrick detects this by analyzing the OpenAPI specification for endpoints that accept tokens and then correlating runtime behavior to identify SQL-related inputs derived from authentication contexts. When scans uncover endpoints where JWT-derived claims are used in query construction, findings include severity details and remediation guidance tied to database interaction patterns. This is distinct from generic SQL injection because it involves trust placed in authenticated identity assertions, making it important to treat all post-verification data as hostile.

To remediate SQL injection risks in Actix when using JWT tokens, always parameterize SQL queries and avoid string interpolation of claims. Use prepared statements with a database library that supports placeholders, ensuring that values from JWT claims are never directly embedded in SQL text. Below are two concrete examples: one using sqlx with query_as and another using parameterized queries with postgres.

Example 1: Using sqlx with query_as

use actix_web::{web, HttpResponse};
use serde::Deserialize;
use sqlx::PgPool;

#[derive(Deserialize)]
struct Claims {
    sub: String,
    role: String,
}

async fn get_user_by_sub(
    pool: web::Data,
    claims: web::Json,
) -> HttpResponse {
    let user = sqlx::query_as!(
        User,
        "SELECT id, username, role FROM users WHERE id = $1",
        claims.sub
    )
    .fetch_one(pool.get_ref())
    .await;

    match user {
        Ok(u) => HttpResponse::Ok().json(u),
        Err(_) => HttpResponse::NotFound().finish(),
    }
}

Example 2: Using the postgres crate with parameterized queries

use actix_web::{web, HttpResponse};
use postgres::{Client, NoTls};

async fn get_tenant_data(claims: web::Json) -> HttpResponse {
    let mut client = Client::connect("host=localhost user=postgres", NoTls).unwrap();
    // Safe: using $1 placeholder with a value from JWT claims
    let rows = client
        .query(
            "SELECT data FROM tenants WHERE tenant_id = $1",
            &[&claims.tenant_id],
        )
        .unwrap();

    HttpResponse::Ok().json(rows)
}

Additionally, enforce strict input validation on JWT claims before use. For example, validate that a sub claim conforms to a UUID format or an integer pattern using Actix extractors and validation libraries. Do not rely on the token’s signature alone to guarantee safety. Combine this with principle-of-least-privilege database roles so that even if injection were possible, the impact would be limited. middleBrick’s scans can surface endpoints where JWT-derived inputs are used in unsafe SQL patterns, providing prioritized findings with severity levels and remediation steps aligned to compliance frameworks such as OWASP API Top 10 and SOC2.

For teams using continuous monitoring, the Pro plan’s GitHub Action can be added to CI/CD pipelines to fail builds if risk scores drop below a defined threshold, while the MCP Server allows you to scan APIs directly from your AI coding assistant within the IDE. These integrations help catch unsafe patterns early, reducing the likelihood of SQL injection issues reaching production.