Formula Injection in Actix with Cockroachdb

Formula Injection occurs when attacker-controlled data is interpreted as part of a query language or formula, enabling unintended behavior. In an Actix web service that uses CockroachDB, this typically arises when dynamic SQL is constructed by interpolating user input into queries that CockroachDB executes. Although CockroachDB supports PostgreSQL wire protocol and standard SQL syntax, Actix applications often build queries with format strings or concatenation, especially when using query_as or raw SQL APIs without parameterization.

Consider an endpoint that filters products by a user-supplied category identifier. If the code uses format! to build a SQL string, an attacker can supply a value like '; DROP TABLE products; -- or a crafted payload that changes the logical structure of the query. With CockroachDB, which shares PostgreSQL semantics, unescaped single quotes break string literal boundaries and enable injection. Even when using ORM-level abstractions, unsafe usage of filter conditions or dynamic ordering can expose injection paths if values are not properly bound.

The risk is compounded when the application exposes database metadata or error messages. CockroachDB error responses can reveal schema details, table names, or index information that an attacker leverages to refine injection vectors. In an Actix service, panics or JSON error handlers that include raw database errors may inadvertently surface these details to clients. Because the scan tests unauthenticated attack surfaces, it can detect endpoints where user input directly influences SQL text, flagging issues such as Authentication weaknesses or Property Authorization bypasses when injection permits privilege escalation or unauthorized data access.

Additionally, Formula Injection in this context includes misuse of query parameters that should be bound but are instead concatenated. For example, sorting or pagination parameters that are interpolated into SQL strings can be abused to inject expressions or modify query behavior. The scanner’s checks for Input Validation and Property Authorization highlight these risks, emphasizing the need to treat all user-controlled data as untrusted, regardless of whether the backend is CockroachDB or another system.

Remediation centers on strict separation of SQL code and data. Use CockroachDB-compatible parameterized queries with Actix’s supported database clients. Avoid string interpolation for identifiers, table names, or dynamic clauses; if dynamic SQL is unavoidable, use a strict allowlist and treat identifiers as metadata, never as user input.

Example of a vulnerable pattern in Actix with CockroachDB:

// UNSAFE: string concatenation leads to Formula Injection
async fn get_products_unsafe(query: web::Query) -> impl Responder {
    let sql = format!("SELECT id, name FROM products WHERE category = '{}'", query.category);
    let rows = sqlx::query(&sql).fetch_all(&pool).await?;
    HttpResponse::Ok().json(rows)
}

Secure alternative using bind parameters:

// SAFE: parameterized query with CockroachDB (PostgreSQL wire protocol)
async fn get_products_safe(query: web::Query) -> impl Responder {
    let rows = sqlx::query("SELECT id, name FROM products WHERE category = $1")
        .bind(&query.category)
        .fetch_all(&pool)
        .await?;
    HttpResponse::Ok().json(rows)
}

When dynamic table or column names are required (e.g., multi-tenant schemas), use an allowlist and map values to identifiers—never directly interpolate user input:

// SAFE: allowlist-based identifier selection
fn resolve_table(tenant_id: &str) -> Option<&'static str> {
    match tenant_id {
        "tenant_a" => Some("tenant_a_data"),
        "tenant_b" => Some("tenant_b_data"),
        _ => None,
    }
}

async fn get_tenant_data(path: web::Path) -> impl Responder {
    let table = resolve_table(&path).unwrap_or("default_table");
    // sqlx requires identifiers to be passed as part of the query string; ensure they are trusted
    let sql = format!("SELECT * FROM {}", table); // table is from allowlist, not user input
    let rows = sqlx::query(&sql).fetch_all(&pool).await?;
    HttpResponse::Ok().json(rows)
}

For sorting and pagination, validate against an allowlist of permitted columns and directions, and construct the SQL safely. Do not allow raw user strings to dictate ORDER BY or LIMIT clauses:

// SAFE: controlled sorting without injection
async fn list_items(
    query: web::Query impl Responder {
    let allowed_columns = ["created_at", "name", "updated_at"];
    let column = if allowed_columns.contains(&query.sort.as_str()) {
        query.sort.as_str()
    } else {
        "created_at"
    };
    let dir = if query.ascending { "ASC" } else { "DESC" };
    // sqlx does not support bind for identifiers; ensure column/dir are from allowlist
    let sql = format!("SELECT id, name FROM items ORDER BY {} {}", column, dir);
    let rows = sqlx::query(&sql).fetch_all(&pool).await?;
    HttpResponse::Ok().json(rows)
}

These patterns align with the scanner’s checks for Input Validation, Authentication, and Property Authorization, ensuring that user data cannot alter query structure. By consistently using bind parameters for values and strict allowlists for identifiers, Actix services against CockroachDB reduce the attack surface for Formula Injection and related issues.