Api Rate Abuse in Axum (Rust)

Rate abuse in an Axum API built with Rust occurs when an endpoint can be called repeatedly without effective enforcement, allowing a single client to consume disproportionate server resources or disrupt service. Axum is a web framework for Rust, and while Rust’s safety guarantees prevent memory safety issues, they do not automatically enforce request-rate limits. Without explicit controls, an attacker can perform credential stuffing, brute-force authentication, or amplify resource consumption (CPU, memory, database connections).

Because Axum is asynchronous and built on Tower, it relies on middleware to implement rate limiting. If developers do not integrate a rate-limiting layer or misconfigure it (for example, applying limits per route but not globally, or using a naive in-memory store in a multi-worker deployment), the attack surface remains open. In a black-box scan, middleBrick tests for the presence and correctness of rate limiting across endpoints and methods, checking for missing limits, weak limits that are too high, and inconsistent enforcement across routes.

Another common pattern is to guard only the login or token endpoint while leaving data endpoints unprotected. This creates a bypass where authenticated or semi-authenticated paths can still be abused. Moreover, using the wrong identifier for rate-limiting (e.g., IP only) can be evaded via NAT or shared proxies, whereas robust implementations combine identifiers like API key or user ID when available. middleBrick’s rate-limiting checks verify that limits are applied consistently, use appropriate granularity, and are not trivially bypassed.

To remediate rate abuse in Axum, integrate a rate-limiting middleware that tracks requests per key and enforces a token-bucket or fixed-window policy. Below are concrete, idiomatic examples using the axum crate combined with tower::limit::RateLimitLayer and governor for robust control.

Example 1: Global rate limit with tower::limit::RateLimitLayer

This applies a simple global limit to all routes using a constant rate. It is suitable for low-complexity services but does not differentiate by user or API key.

use axum::{routing::get, Router};
use tower_http::limit::RateLimitLayer;
use std::time::Duration;

// Allow 20 requests per second per connection (identified by peer)
let layer = RateLimitLayer::new(20, Duration::from_secs(1));
let app = Router::new()
    .route("/health", get(|| async { "ok" }))
    .layer(layer);

Example 2: Per-user rate limiting with governor and tower-layer

This uses governor to define a quota and a custom tower layer that extracts a user identifier (e.g., from an API key header) to scope limits. This is more precise and avoids affecting unrelated clients.

use axum::{async_trait, extract::Extension, routing::get, Json, Router};
use governor::{Quota, RateLimiter};
use governor::clock::DefaultClock;
use governor::state::NotKeyed;
use std::num::NonZeroU32;
use std::sync::Arc;
use tower_http::auth::{self, AuthLayer};
use tower_http::auth::authorization::BearerAuthorization;

// Define a quota of 100 requests per 60 seconds
let quota = Quota::per_minute(NonZeroU32::new(100).unwrap());
let rate_limiter = Arc::new(RateLimiter::direct(quota));

async fn handler() -> &'static str {
    "limited"
}

// Build app with auth and rate limiting
let app = Router::new()
    .route("/api/data", get(handler))
    .layer(AuthLayer::new_with_connector(
        auth::DefaultMakeAuthorization::bearer(),
        // connector that extracts user ID from token; simplified here
        tower::service_fn(|_: &str| async { Ok::<_, std::convert::Infallible>(None) }),
    ))
    .layer(Extension(rate_limiter));

Example 3: MiddleBrick detection aligns with these patterns

When you deploy these controls, middleBrick’s rate-limiting checks will validate that limits are scoped appropriately, that headers like Retry-After are present when needed, and that no public endpoint lacks protection. For high-assurance deployments, combine global and per-identity limits, and monitor metrics exported by your runtime to detect anomalies.