Sql Injection Union in Actix (Rust)

SQL Injection via UNION-based techniques targets API endpoints that build dynamic SQL strings without parameterization. In an Actix web service written in Rust, this typically occurs when query parameters are concatenated into SQL statements passed to a database driver such as postgres or sqlx. An attacker can inject a UNION SELECT payload to append additional queries, read from unrelated tables, and extract data not intended to be returned.

Consider an Actix handler that constructs SQL based on an id query parameter:

async fn get_user(req: web::Query<HashMap<String, String>>) -> impl Responder {
    let id = req.get("id").unwrap_or("1");
    let query = format!("SELECT username, email FROM users WHERE id = {id}");
    // Assume client is a postgres::Client
    match client.query(&query, &[]).await {
        Ok(rows) => HttpResponse::Ok().json(rows),
        Err(_) => HttpResponse::InternalServerError().finish(),
    }
}

If the id parameter is user-controlled and not validated or parameterized, an attacker can supply 1 UNION SELECT username, password FROM users--, turning the query into:

SELECT username, email FROM users WHERE id = 1 UNION SELECT username, password FROM users--

This leverages the UNION attack to pull sensitive columns from another table. Actix does not introduce a unique SQL Injection vector; it simply passes the request to the underlying Rust database driver. The risk arises when developers treat the database layer as trusted and fail to apply parameterized queries or input validation. The same UNION injection can be used to infer schema, bypass authentication, or achieve vertical privilege escalation depending on the database permissions.

In the context of middleBrick’s checks, an unauthenticated scan can detect this by sending UNION-based probes and analyzing whether error messages or anomalous data appear in responses. The detection does not imply the engine modifies queries; it reports the observable risk. Remediation guidance provided by middleBrick will reference secure coding patterns specific to Rust and Actix, such as using prepared statements and strict input allow-listing.

Rust’s strong type system and ownership model do not automatically prevent SQL Injection; they must be used correctly. The primary fix is to replace string interpolation with parameterized queries. Both postgres and sqlx support bind parameters, which ensure user input is never interpreted as SQL syntax.

Below is a secure version of the previous handler using sqlx with query parameters:

use actix_web::{web, HttpResponse};
use sqlx::postgres::PgPool;
use std::sync::Arc;

async fn get_user_safe(
    pool: web::Data<Arc<PgPool>>,
    web::Query(params): web::Query<HashMap<String, String>>,
) -> HttpResponse {
    let id_str = params.get("id").unwrap_or("1");
    // Validate and parse to the expected type; reject non-numeric input early
    let id = match id_str.parse::

use postgres::{Client, NoTls};

fn get_user_postgres(client: &mut Client, id_input: &str) -> Result<(), Box<dyn std::error::Error>> {
    // Validate input before using it; here we enforce integer-like input
    let id: i32 = id_input.parse()?;
    // Parameterized statement; $1 is a placeholder
    let stmt = client.prepare("SELECT username, email FROM users WHERE id = $1")?;
    let rows = client.query(&stmt, &[&id]);
    // Process rows safely
    Ok(())
}