Insecure Design in Axum with Cockroachdb

Insecure design in an Axum service that uses CockroachDB often arises from coupling application-level routing and business logic with database interaction patterns that bypass authorization and validation. When endpoints construct SQL dynamically or fail to enforce row-level checks per request, the unauthenticated attack surface expands.

Consider an Axum handler that builds a SQL query by concatenating a user-supplied identifier directly into a string. In CockroachDB, which uses PostgreSQL wire protocol and standard SQL syntax, this pattern is compatible but unsafe. An attacker can supply an identifier such as 1; SELECT * FROM system.users --, and if the application does not enforce least-privilege database permissions, the injected statement may read sensitive metadata or configuration tables. Because CockroachDB supports multi-statement execution and offers rich information_schema views, the exposure risk is higher than with simpler embedded databases.

Another insecure design is missing row-level ownership checks. An endpoint like /accounts/{account_id}/profile might issue a query such as SELECT * FROM profiles WHERE id = $1 without verifying that the authenticated principal (if any) owns that account_id. In Axum, if the authorization guard is omitted or applied inconsistently across routes, the same database user can traverse records belonging to other tenants or contexts. This is a BOLA/IDOR pattern enabled by an insecure design choice to skip ownership validation at the handler layer.

Middleware or extractor logic that shares a single CockroachDB connection pool without per-request transaction boundaries can also lead to insecure design. If handlers assume that previous middleware has established tenant context and reuse connections without explicit transaction demarcation, a request may inadvertently operate in the wrong tenant’s scope. CockroachDB’s serializable isolation is strong, but application-level scoping must be enforced; otherwise, reads or writes from one request may be misinterpreted as belonging to another due to connection reuse.

Insecure design is also evident when error handling exposes database structure. Axum handlers that map SQL errors directly into HTTP responses might return constraint names, table names, or schema details. CockroachDB error messages can include schema objects, and without sanitization, these details help an attacker refine injection or enumeration. Proper design requires mapping errors to generic messages while logging detailed diagnostics securely.

Finally, missing validation of numeric or UUID inputs at the handler level enables type confusion or injection. If an Axum extractor casts a string to a numeric ID without range or format checks, and the subsequent CockroachDB query uses that value in an IN clause or as a sort column, unexpected behavior or injection may occur. Designing endpoints with strict validation before database interaction is essential to reduce the attack surface.

Remediation focuses on parameterized queries, explicit tenant scoping, and strict input validation. Avoid string concatenation for SQL; use prepared statements with positional parameters. Below are concrete Axum examples with CockroachDB using tokio-postgres with TLS and bb8 for connection pooling.

1. Parameterized query with row ownership check

use axum::{routing::get, Router, Extension, http::StatusCode};
use bb8_postgres::PostgresConnectionManager;
use tokio_postgres::NoTls; // or use tls via native-tls-rustls
use std::sync::Arc;
use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize)]
struct ProfileParams {
    account_id: i64,
}

#[derive(Debug, Serialize)]
struct Profile {
    id: i64,
    display_name: String,
    owner_account_id: i64,
}

async fn get_profile(
    Extension(pool): Extension<Arc<bb8::Pool<PostgresConnectionManager<NoTls>>>,
    params: axum::extract::Query<ProfileParams>
) -> Result<axum::Json<Profile>, (StatusCode, String)> {
    let mut conn = pool.get().await.map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    let row = conn
        .query_opt(
            "SELECT id, display_name, owner_account_id FROM profiles WHERE id = $1 AND owner_account_id = $2",
            &[¶ms.id, ¶ms.account_id],
        )
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    match row {
        Some(r) => Ok(axum::Json(Profile {
            id: r.get(0),
            display_name: r.get(1),
            owner_account_id: r.get(2),
        })),
        None => Err((StatusCode::NOT_FOUND, "Profile not found".to_string())),
    }
}

fn app() -> Router {
    // Assume pool is built with bb8 and a CockroachDB URL
    Router::new()
        .route("/accounts/:account_id/profile", get(get_profile))
}

This ensures the database performs both lookup and ownership check in a single parameterized query, eliminating BOLA risks.

2. Use explicit transactions and tenant context

use tokio_postgres::Transaction;

async fn write_cross_records(
    tx: &mut Transaction<NoTls>,
    tenant_id: i64,
    updates: Vec<(i64, String)>
) -> Result<, tokio_postgres::Error> {
    for (record_id, new_value) in updates {
        tx.execute(
            "UPDATE tenant_records SET value = $1 WHERE tenant_id = $2 AND record_id = $3",
            &[&new_value, &tenant_id, &record_id],
        ).await?;
    }
    Ok(())
}

Call this within an Axum handler where the tenant context is extracted and a transaction is started explicitly. This prevents connection reuse issues and ensures atomic updates scoped to a tenant.

3. Input validation and sanitization

use validator::Validate;

#[derive(Debug, Validate, Deserialize)]
struct CreateUser {
    #[validate(range(min = 1))]
    account_id: i64,
    #[validate(length(min = 1, max = 255))]
    email: String,
}

async fn create_user_handler(
    user: axum::extract::Json<CreateUser>
) -> Result<axum::Json<()>, (StatusCode, String)> {
    user.validate().map_err(|e| (StatusCode::BAD_REQUEST, e.to_string()))?;
    // proceed with parameterized insert
    Ok(axum::Json(()))
}

Validate before constructing SQL. This prevents malformed inputs from reaching CockroachDB and reduces injection surface.

4. Error handling that avoids schema disclosure

use axum::response::IntoResponse;

fn handle_db_error(err: tokio_postgres::Error) -> impl IntoResponse {
    // Log full error internally
    tracing::error!("DB error: {}", err);
    // Return generic message to client
    (StatusCode::INTERNAL_SERVER_ERROR, "Internal error").into_response()
}

Map CockroachDB errors to generic responses to prevent information leakage while preserving observability through internal logs.