Privilege Escalation in Axum with Cockroachdb

Privilege Escalation (BFLA) occurs when an application exposes administrative or other elevated operations over a user-context endpoint without verifying that the requesting user is authorized to perform that action. When an Axum service uses Cockroachdb as its backend, the risk arises from a mismatch between application-level authorization and database-level permissions, combined with overly permissive API routes that do not validate scope or role before executing privileged SQL.

In Axum, handlers often receive a user identity (for example via JWT claims) and construct SQL queries or call repository methods that interact with Cockroachdb. If the handler does not enforce per-request authorization checks—such as confirming the user owns the targeted resource or has a role like admin or superuser—an attacker can tamper with identifiers (e.g., changing a URL parameter from user_id=100 to user_id=101) or manipulate request body fields to invoke admin-only endpoints.

Cockroachdb’s SQL interface does not inherently understand application roles; it enforces SQL-level user permissions only. If the application connects to Cockroachdb with a highly privileged service account (for simplicity or convenience), a single compromised endpoint can allow an attacker to execute statements as that service account. Examples include dropping tables, reading sensitive columns, or modifying configuration tables. Even when application logic attempts to filter by tenant_id, inadequate validation or missing row-level security assumptions can allow horizontal privilege escalation across tenants or vertical escalation to admin functions.

Real-world attack patterns mirror the OWASP API Top 10 A01:2023 broken access control. A typical scenario: an endpoint DELETE /users/{id} in Axum deserializes {id} from the path, passes it to a SQL statement like DELETE FROM users WHERE id = $1 using a pooled Cockroachdb connection with broad privileges, and omits checks such as is_admin or is_own_user. An authenticated user can change the ID to another user’s identifier and, if the endpoint lacks proper authorization, trigger a deletion they should not perform. In clustered setups with Cockroachdb, misconfigured database roles or lack of per-request role mapping can compound this by allowing broader SQL permissions than intended.

To detect such issues, middleBrick runs checks that include BFLA/Privilege Escalation among its 12 parallel security scans. It tests unauthenticated and authenticated contexts where possible, validates whether endpoints enforce ownership or role checks, and inspects how identifiers are handled before being passed to persistence layers. This helps surface endpoints in Axum that inadvertently expose dangerous operations when backed by Cockroachdb.

Remediation focuses on three layers: database permissions, application-level authorization, and request validation. Use Cockroachdb roles and row-level security (RLS) to enforce least privilege, and ensure Axum handlers validate ownership and scope before issuing SQL.

1. Database roles and least privilege

Create distinct Cockroachdb roles for application operations and avoid using a highly privileged account for routine requests. For example, define a read-write role for tenant members and a separate read-only role where appropriate. In Cockroachdb, you can grant limited privileges to a role and use parameterized queries from Axum without embedding superuser credentials in every handler.

-- Cockroachdb SQL: create roles and grant minimal privileges
CREATE ROLE tenant_user;
CREATE ROLE tenant_admin;

-- Example users assigned per tenant or per context
CREATE USER web_user_101 WITH PASSWORD '***';
GRANT tenant_user TO web_user_101;

CREATE USER web_admin_101 WITH PASSWORD '***';
GRANT tenant_admin TO web_admin_101;

-- Table with tenant isolation and optional RLS
CREATE TABLE users (
  id UUID PRIMARY KEY,
  tenant_id UUID NOT NULL,
  email TEXT NOT NULL,
  is_admin BOOLEAN DEFAULT FALSE
);

-- Enable row-level security on the table
ALTER TABLE users ENABLE ROW LEVEL SECURITY;

-- Policy: tenant members can see and modify only their own rows
CREATE POLICY tenant_isolation_policy ON users
  FOR ALL
  USING (tenant_id = current_setting('app.tenant_id', true)::UUID)
  WITH CHECK (tenant_id = current_setting('app.tenant_id', true)::UUID);

-- Admin override policy (only admins can see all rows)
CREATE POLICY admin_override_policy ON users
  FOR SELECT
  TO tenant_admin
  USING (true);

2. Axum handlers with explicit authorization checks

In Axum, always extract user claims, verify ownership or admin status, and pass tenant context to Cockroachdb via session variables. Avoid constructing SQL by string concatenation; use strongly typed queries with types like sqlx or diesel with parameterized statements.

// Rust example using Axum + sqlx with Cockroachdb
use axum::{routing::get, Router, extract::State, http::StatusCode};
use serde::Serialize;
use sqlx::postgres::PgConnectOptions;
use sqlx::ConnectOptions;
use std::net::SocketAddr;
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};

struct AppState {
    pool: sqlx::PgPool,
    jwt_secret: String,
}

#[derive(Debug, Serialize)]
struct UserClaims {
    sub: String,
    tenant_id: String,
    is_admin: bool,
}

async fn delete_user_handler(
    State(state): State<AppState>,
    // In practice, extract user_id from path and JWT from Authorization header
    user_id: String,
    auth_header: Option<axum::extract::Header<axum::http::header::AUTHORIZATION>>,
) -> Result<impl axum::response::IntoResponse, (StatusCode, String)> {
    let token = auth_header.ok_or((StatusCode::UNAUTHORIZED, "Missing token".to_string()))?;
    let token = token.to_str().map_err(|_| (StatusCode::UNAUTHORIZED, "Invalid header".to_string()))?;
    let decoded = decode::