Api Rate Abuse in Axum with Session Cookies

Rate abuse occurs when an attacker makes excessive requests to an endpoint, degrading availability or enabling financial or data exfiltration attacks. In Axum, a common pattern uses session cookies for identity, which can inadvertently weaken rate-limiting defenses if the boundary between authentication and authorization is not explicit. When session cookies are used without a corresponding request-level throttle, an unauthenticated or low-assurance identity can still flood the application with authenticated-looking traffic, consuming server and database resources.

Consider an endpoint that relies on session cookies to identify a user but does not enforce independent rate limits per session or per originating IP. An attacker who discovers or guesses a valid session cookie—perhaps via cross-site scripting, insecure token storage, or a session fixation flaw—can reuse that cookie to bypass IP-based controls. Because the server treats each request as legitimate, the lack of per-session or per-identity throttling allows high-volume scraping, brute-force credential attempts, or resource-intensive operations to proceed unchecked.

Additionally, if rate limiting is applied only after session validation, an attacker can trigger CPU-intensive middleware or database queries before rejection, leading to denial of service. For example, a login or profile endpoint that loads user data from a database on every request becomes expensive when called repeatedly with a valid session. Without per-session counters combined with global and IP-level limits, the system may exhaust connection pools, thread pools, or memory, causing legitimate traffic to fail.

middleBrick detects such patterns in its Rate Limiting checks by analyzing runtime behavior against the declared API contract, including how authentication mechanisms like session cookies interact with request volume. Findings include risk ratings and remediation guidance mapped to frameworks such as OWASP API Top 10 and PCI-DSS, highlighting unsafe consumption patterns and missing controls. Continuous monitoring in the Pro plan can alert you when request rates for a session or identity exceed expected thresholds, helping you catch abuse before it impacts availability.

To secure Axum applications using session cookies, apply rate limiting at multiple layers and ensure each session has identifiable context for monitoring. Use tower-based middleware to enforce per-session and global limits, and avoid relying solely on IP-based controls when authenticated sessions are present.

use axum::{
    async_trait, body::Body, extract::Request, http::Response, Router,
};
use std::net::SocketAddr;
use std::sync::Arc;
use std::time::Duration;
use tower::ServiceBuilder;
use tower_http::auth::{AuthLayer, Credentials};
use tower_http::set_header::SetResponseHeaderLayer;
use tower_http::time::RateLimitLayer;

// A simple session store keyed by session ID (in production, use a robust store)
struct SessionStore {
    limits: std::collections::HashMap,
}

impl SessionStore {
    fn new() -> Self {
        Self {
            limits: std::collections::HashMap::new(),
        }
    }

    fn check_and_increment(&mut self, session_id: &str, max: usize, window: Duration) -> bool {
        let entry = self.limits.entry(session_id.to_string()).or_insert((0, Instant::now()));
        if entry.1.elapsed() > window {
            entry.0 = 1;
            entry.1 = Instant::now();
            true
        } else if entry.0 < max {
            entry.0 += 1;
            true
        } else {
            false
        }
    }
}

#[tokio::main]
async fn main() {
    let session_store = Arc::new(std::sync::Mutex::new(SessionStore::new()));

    // Apply per-session rate limiting via a custom tower service
    let rate_limit_layer = ServiceBuilder::new()
        .layer_fn(move |service| {
            let store = Arc::clone(&session_store);
            tower::service_fn(move |req: Request| {
                let store = store.lock().unwrap();
                let session_id = req.headers()
                    .get("cookie")
                    .and_then(|c| c.to_str().ok())
                    .and_then(|c| c.split('=').nth(1)) // naive parsing; use a cookie parser in production
                    .unwrap_or("unknown")
                    .to_string();

                // Allow max 30 requests per minute per session
                let allowed = store.check_and_increment(&session_id, 30, Duration::from_secs(60));
                if allowed {
                    service.call(req)
                } else {
                    futures::future::ready(Ok(Response::builder()
                        .status(429)
                        .body(Body::from("Too Many Requests"))
                        .unwrap()))
                }
            })
        });

    let app = Router::new()
        .route("/profile", axum::routing::get(profile_handler))
        .layer(rate_limit_layer)
        .layer(AuthLayer::with_default_service::<_, Credentials>(
            Arc::new(|credentials: Credentials| async move {
                // Validate session cookie and return identity
                Ok(credentials)
            }),
        ));

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

async fn profile_handler() -> &'static str {
    "profile data"
}

In this example, session cookies are parsed to derive a session identifier, and a per-session sliding window counter enforces a limit of 30 requests per minute. Combine this with a global limit using additional tower layers or a dedicated rate-limiting crate to protect against distributed abuse. For production, replace the in-memory store with Redis or a database-backed solution to share state across workers and ensure accuracy under concurrency.

Additionally, set short cookie lifetimes, use Secure and HttpOnly flags, and rotate session identifiers after login to reduce the impact of cookie theft. middleBrick’s CLI can be used to scan your Axum endpoints and validate that rate-limiting controls are observable in runtime behavior. If you need to integrate checks into your development workflow, the GitHub Action can fail builds when risk scores exceed your defined thresholds, while the MCP Server allows you to scan APIs directly from your IDE.