Integer Overflow in Axum with Cockroachdb

An integer overflow in an Axum application that uses CockroachDB can occur when user-supplied numeric values are used in calculations that affect database operations, such as constructing pagination offsets or computing array indices before issuing SQL queries. Axum, being a Rust web framework, does not automatically protect against arithmetic overflow in debug or release builds depending on configuration, and CockroachDB, while strongly consistent, will still execute the SQL you send. If an attacker can influence a numeric parameter that is added to a cursor or multiplied to compute a limit, the resulting value may wrap around to a small number or become zero, causing the query to return an unexpected or very large result set. This can lead to data exposure or excessive resource consumption.

For example, consider an endpoint that accepts a page and page_size query parameters to fetch rows from a CockroachDB table. If page_size is parsed as a 32-bit integer and multiplied by page to compute an offset, a large page value can cause the multiplication to overflow. In Axum, this calculation typically happens in Rust code before forming a query such as SELECT * FROM accounts LIMIT $1 OFFSET $2. If the overflow wraps to a small number, an attacker may be able to read rows they should not see or trigger heavy scans by forcing large offsets. Even when using CockroachDB’s safe integer handling on the server, the client-side computation in Axum must be correct to avoid malformed queries or information leaks.

Another scenario involves identifiers derived from user input, such as an account ID used in a WHERE clause. If an attacker manipulates the ID and it overflows before being sent to CockroachDB, the resulting SQL may match unintended rows due to wrap-around values. This intersects with BOLA/IDOR when the computed identifier maps to a different, accessible resource. Because CockroachDB returns results based on the actual numeric value it receives, Axum must validate and sanitize inputs before constructing SQL, ensuring that values remain within expected bounds and do not wrap.

In a real API, you might build dynamic filters that sum numeric fields or increment counters before writing to CockroachDB. If these increments are performed without checking for overflow in Axum, an attacker submitting specially crafted numeric payloads could cause the calculation to wrap, leading to incorrect data being stored or retrieved. This can undermine integrity checks and expose more data than intended. The risk is higher when APIs accept JSON numeric fields that are directly translated into SQL numeric parameters without range checks.

Because middleBrick scans the unauthenticated attack surface and tests input validation and data exposure, it can surface these classes of issues by detecting unexpected data returns or missing bounds checks. The scanner’s inventory management and input validation checks look for places where numeric inputs flow into SQL generation in Axum and then to CockroachDB, highlighting where attacker-controlled values can influence query behavior.

To prevent integer overflow in Axum when interacting with CockroachDB, perform explicit checks before arithmetic and use safe types and parameters. Prefer 64-bit integers where possible and validate ranges against expected limits, especially for pagination and identifiers. Below are concrete code examples that demonstrate secure patterns.

First, validate page and page_size before computing offset. Use checked arithmetic to ensure no wrap occurs.

use axum::extract::Query;
use serde::Deserialize;

#[derive(Deserialize)]
pub struct PaginationQuery {
    page: u64,
    page_size: u64,
}

pub async fn list_users(Query(query): Query) -> Result

use sqlx::PgPool;

pub async fn increment_balance(pool: &PgPool, account_id: i64, delta: i64) -> Result<(), sqlx::Error> {
    if delta < 0 && delta < i64::MIN + 1000 { // example sanity check
        return Err(sqlx::Error::RowNotFound);
    }
    sqlx::query("UPDATE accounts SET balance = balance + $1 WHERE id = $2")
        .bind(delta)
        .bind(account_id)
        .execute(pool)
        .await?;
    Ok(())
}

sqlx::query("ALTER TABLE accounts ADD CONSTRAINT positive_balance CHECK (balance >= 0)")
    .execute(&pool)
    .await?;