Api Rate Abuse in Axum with Mysql

Rate abuse in an Axum service backed by MySQL becomes likely when rate limiting is enforced only in application logic or is missing entirely. Axum does not provide built-in rate limiting, so developers must add it explicitly. Without it, an unauthenticated or weakly authenticated API endpoint can be called repeatedly, allowing an attacker to exhaust MySQL connections, trigger heavy query loads, or amplify other findings such as BOLA/IDOR by iterating over identifiers at high speed.

When each Axum request opens a new MySQL connection or long-lived transaction without throttling, the database can reach its max_connections limit, causing legitimate traffic to be rejected. Additionally, endpoints that perform non-indexed queries or return large result sets can degrade MySQL performance under sustained load, leading to high latency or timeouts. This is especially risky when combined with input validation issues, since malformed or unexpected queries can cause full table scans that further stress the database.

Rate abuse also interacts with authentication and authorization checks. If authentication is deferred or bypassed, attackers can probe user-specific endpoints without cost, iterating through user IDs and observing differences in response timing or status codes. MiddleBrick’s Authentication and Rate Limiting checks can detect missing or weak controls, while the BOLA/IDOR checks highlight endpoints that expose data without proper ownership verification. Together, these create a chain where rate abuse enables enumeration and data exposure through MySQL-backed Axum services.

In practice, an attacker might send hundreds of requests per second to /users/{id} endpoints, attempting to infer valid user IDs or trigger database-level errors that leak stack traces or schema details. If the Axum route does not enforce per-IP or per-token limits, and MySQL slow query logging is not enabled, the abuse may go unnoticed until performance degrades or connections are exhausted. Continuous monitoring and coordinated limits at both the application and database layers are essential to reduce this risk surface.

Remediation focuses on adding robust rate limiting, efficient database access, and defensive query patterns in Axum while keeping MySQL usage safe and predictable. Use middleware to enforce global and per-user limits, and ensure database interactions use prepared statements, timeouts, and proper indexing to avoid abuse-driven load.

First, apply a rate limit middleware in Axum to restrict requests per IP or per authenticated token. This reduces the volume of queries reaching MySQL and prevents connection exhaustion:

use axum::middleware::next;
use axum::response::Response;
use std::net::SocketAddr;
use std::sync::Arc;
use tokio::sync::RwLock;

struct RateLimiter {
    limits: RwLock>,
}

impl RateLimiter {
    async fn allow(&self, key: &str) -> bool {
        let limits = self.limits.read().await;
        limits.get(key).map_or(true, |&count| count < 100)
    }
    async fn record(&self, key: &str) {
        let mut limits = self.limits.write().await;
        *limits.entry(key.to_string()).or_insert(0) += 1;
    }
}

async fn rate_limit_middleware(
    addr: SocketAddr,
    state: Arc<RateLimiter>,
    mut req: Request,
    next: next::Next,
) -> Result<Response, (StatusCode, String)> {
    let key = addr.ip().to_string();
    if state.allow(&key).await {
        state.record(&key).await;
        Ok(next.run(req).await)
    } else {
        Err((StatusCode::TOO_MANY_REQUESTS, "Rate limit exceeded".into()))
    }
}

#[tokio::main]
async fn main() {
    let state = Arc::new(RateLimiter { limits: RwLock::new(std::collections::HashMap::new()) });
    let app = Router::new()
        .route("/users/:id", get(get_user))
        .layer(middleware::from_fn_with_state(state, rate_limit_middleware));
    axum::Server::bind(&"0.0.0.0:3000".parse().unwrap())
        .serve(app.into_make_service())
        .await
        .unwrap();
}

Second, use parameterized queries with a connection pool to avoid SQL injection and ensure predictable resource usage:

use sqlx::mysql::MySqlPoolOptions;
use sqlx::Row;

#[derive(Debug)]
struct User {
    id: i32,
    name: String,
}

async fn get_user(pool: &sqlx::MySqlPool, user_id: i32) -> Result<User, sqlx::Error> {
    let row = sqlx::query("SELECT id, name FROM users WHERE id = ?")
        .bind(user_id)
        .fetch_one(pool)
        .await?;
    Ok(User {
        id: row.try_get("id")?,
        name: row.try_get("name")?,
    })
}

#[tokio::main]
async fn main() -> Result<(), sqlx::Error> {
    let pool = MySqlPoolOptions::new()
        .connect("mysql://user:password@localhost/dbname")
        .await?;
    let user = get_user(&pool, 42).await?;
    println!("{:?}", user);
    Ok(())
}

Third, enforce query timeouts and validate input ranges to prevent abusive long-running queries:

use sqlx::mysql::MySqlConnectOptions;
use std::time::Duration;

async fn safe_query(user_id: i32) -> Result<(), sqlx::Error> {
    let opts = MySqlConnectOptions::new()
        .connect_timeout(Some(Duration::from_secs(2)))
        .to_owned();
    let mut conn = opts.connect("mysql://user:password@localhost/dbname").await?;
    let result: (i64,) = sqlx::query_as("SELECT COUNT(*) FROM orders WHERE user_id = ? AND created_at > NOW() - INTERVAL 30 DAY")
        .bind(user_id)
        .timeout(Duration::from_secs(5))
        .fetch_one(&mut conn)
        .await?;
    if result.0 > 1000 {
        return Err(sqlx::Error::RowNotFound);
    }
    Ok(())
}

Finally, create appropriate indexes and monitor query patterns to ensure MySQL can handle legitimate traffic without enabling abuse:

-- Ensure user_id is indexed to avoid full table scans
CREATE INDEX idx_users_id ON users(id);

-- Monitor long-running queries and set max execution time per session
SET GLOBAL max_execution_time=5000;

These steps reduce the likelihood of rate abuse affecting MySQL through an Axum service by combining application-layer throttling, safe query patterns, and database-side protections.