Api Key Exposure in Axum with Cockroachdb

When building a Rust API service with Axum and Cockroachdb, developers often move sensitive credentials such as database connection strings or external API keys into environment variables. If these environment variables are logged, echoed in error messages, or inadvertently included in structured API responses, they can be exposed through the application’s runtime endpoints. middleBrick detects this exposure as Data Exposure by scanning unauthenticated attack surfaces and identifying places where secrets might be returned in HTTP responses or rendered in debug output.

In Axum, a common pattern routes requests through layers that capture database pools and external keys. If error handling or health-check endpoints serialize configuration structs that contain string fields for credentials, those endpoints can become accidental leakage channels. For example, a handler that returns the full DatabaseConfig struct for debugging purposes can expose the connection URI, which often embeds transient API keys or database tokens. middleBrick’s cross-referencing of the OpenAPI spec with runtime findings highlights mismatches where responses include fields that should never be public, such as db_url or api_key.

Cockroachdb-specific drivers in Axum typically use connection strings that include authentication tokens. If the application reuses these strings across services or embeds them in logging statements, a single exposed endpoint can reveal credentials that grant access to sensitive tenant data. The scanner checks for Data Exposure across response schemas, server headers, and error payloads, flagging any occurrence of credential-like patterns in JSON or XML output. This is especially relevant when combined with SSRF or unsafe consumption checks, where an attacker might coax the server into returning internal configuration objects that include Cockroachdb connection details.

Additionally, improper input validation in Axum handlers can allow an attacker to manipulate query parameters or headers in ways that cause the application to dump configuration for introspection. If these introspection endpoints include environment-derived values, the response may contain API keys or database tokens. middleBrick’s Input Validation and Data Exposure checks work in parallel to identify such risky endpoints, providing remediation guidance that focuses on filtering sensitive fields before serialization and ensuring that configuration structs are not exposed through public routes.

To prevent Api Key Exposure when using Cockroachdb with Axum, you should isolate sensitive configuration from runtime responses and enforce strict serialization rules. Below are concrete, working examples that demonstrate secure patterns.

First, define configuration structs that omit sensitive fields from public serialization. Use serde::skip to ensure keys are never accidentally included in API responses.

use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize)]
pub struct DatabaseConfig {
    pub host: String,
    pub port: u16,
    pub username: String,
    #[serde(skip)]
    pub password: String,
    #[serde(skip)]
    pub api_key: String,
}

Second, create a separate internal configuration loader that builds the Cockroachdb connection string without exposing it in handlers. Use environment variables via std::env and construct the connection URI only when initializing the database pool.

use cockroachdb_rs::Connection;
use std::env;

fn build_db_pool() -> Connection {
    let host = env::var("DB_HOST").unwrap_or_else(|_| "localhost".into());
    let port = env::var("DB_PORT").unwrap_or_else(|_| "26257".into());
    let user = env::var("DB_USER").unwrap_or_else(|_| "root".into());
    let password = env::var("DB_PASSWORD").expect("DB_PASSWORD must be set");
    let db_name = env::var("DB_NAME").expect("DB_NAME must be set");
    let conn_str = format!(
        "postgresql://{}:{}@{}:{}/{}?sslmode=require",
        user, password, host, port, db_name
    );
    Connection::connect(&conn_str).expect("Failed to connect to Cockroachdb")
}

Third, ensure health-check and introspection endpoints do not echo configuration. Instead of returning the full config, return a minimal status object.

use axum::Json;
use serde::Serialize;

#[derive(Serialize)]
pub struct HealthStatus {
    pub status: &'static str,
    pub service: &'static str,
}

pub async fn health_check() -> Json<HealthStatus> {
    Json(HealthStatus {
        status: "ok",
        service: "api",
    })
}

Finally, apply input validation to reject requests that attempt to probe for configuration details. Use Axum extractors to filter and sanitize inputs, and avoid passing raw environment variables into response bodies. middleBrick’s checks for Data Exposure and Input Validation help verify that these patterns are correctly implemented in practice.