Data Exposure in Actix with Cockroachdb

The Data Exposure check in middleBrick examines whether an API returns sensitive information such as credentials, personally identifiable information (PII), or internal identifiers in responses. When an Actix service uses Cockroachdb as its backend, several patterns specific to this combination can unintentionally expose data.

First, if query building in Actix does not consistently parameterize inputs against Cockroachdb, responses may include raw database identifiers, timestamps, or error details that reveal schema information. For example, returning an entire row—including internal primary keys and tenant identifiers—can expose relationships that should remain internal. In distributed Cockroachdb deployments, responses may inadvertently surface node-specific metadata or transaction retry artifacts when error handling in Actix is not strict.

Second, serialization logic in Actix that maps Cockroachdb rows directly into JSON can include fields that should be filtered, such as internal audit columns (e.g., created_by, updated_at, or internal flags). Without explicit field selection or struct-based serialization, developers may expose more data than intended. middleBrick’s Data Exposure check tests whether responses include credentials, keys, or sensitive PII, and flags cases where Cockroachdb-backed endpoints return broad or unfiltered data structures.

Third, Cockroachdb’s wire protocol and SQL dialect differences can interact with Actix’s runtime behavior in ways that expose data through verbose error messages. For instance, a missing row due to a conditional WHERE clause may return stack traces or query details in development configurations, which can leak information about table structures or indexes. middleBrick scans these unauthenticated endpoints and checks responses for sensitive content, providing severity-ranked findings with remediation guidance specific to Actix and Cockroachdb integrations.

To prevent Data Exposure when using Actix with Cockroachdb, ensure strict selection of returned fields, robust error handling, and safe serialization. Below are concrete, working code examples that demonstrate secure patterns.

1. Use Selective Structs Instead of Exposing Full Rows

Define response structs that include only necessary fields. This prevents accidental exposure of internal Cockroachdb columns.

use actix_web::{web, HttpResponse};
use serde::Serialize;

#[derive(Serialize)]
pub struct UserPublic {
    pub id: i64,
    pub email: String,
    pub display_name: String,
}

pub async fn get_user(info: web::Path) -> HttpResponse {
    let user_id = info.into_inner();
    // Example using `cockroachdb.rs` or similar driver
    let row = crate::db::query_one(
        "SELECT id, email, display_name FROM users WHERE id = $1",
        &[&user_id],
    )
    .await;

    match row {
        Ok(r) => HttpResponse::Ok().json(UserPublic {
            id: r.get(0),
            email: r.get(1),
            display_name: r.get(2),
        }),
        Err(_) => HttpResponse::NotFound().finish(),
    }
}

2. Avoid Returning Raw Database Errors to Clients

Map Cockroachdb errors to generic messages to prevent information leakage about schema or node details.

use actix_web::{error, Error};
use actix_web::HttpResponse;

pub fn handle_db_error(err: impl std::fmt::Debug) -> Error {
    // Log the full error internally for diagnostics
    tracing::error!(error = ?err, "Database error occurred");
    // Return a generic response to avoid exposing internals
    actix_web::error::ErrorInternalServerError("An internal error occurred")
}

3. Use Parameterized Queries to Prevent Injection-Driven Data Exposure

Always use placeholders ($1, $2) with Cockroachdb to avoid dynamic SQL that may expose data through error messages or logs.

// Safe parameterized query example
sqlx::query(
    "UPDATE profiles SET display_name = $1 WHERE user_id = $2",
)
.bind(new_name)
.bind(user_id)
.execute(&pool)
.await?;

4. Disable Verbose Debug Modes in Production

Ensure Actix’s debug logging or `RUST_LOG` settings do not output SQL or internal errors that could reveal Cockroachdb internals.

// In production configuration, avoid `RUST_LOG=debug`
// Use environment-based configuration:
// .env
// RUST_LOG=info
// ACTIX_LOG_LEVEL=info

5. Validate and Filter Input to Reduce Over-fetching

Limit queries to necessary columns and rows, reducing the chance of exposing sensitive fields stored in Cockroachdb.

// Only fetch required columns
let sql = "SELECT id, email FROM users WHERE tenant_id = $1 AND active = $2";
let users: Vec<UserPublic> = sqlx::query_as(sql)
    .bind(tenant_id)
    .bind(true)
    .fetch_all(&pool)
    .await?;