Broken Authentication in Actix with Mongodb

Broken Authentication in an Actix application using Mongodb often stems from a mismatch between session management design and how credentials are stored, validated, and transmitted. Actix is a Rust web framework that relies heavily on typed, async handlers and extractor patterns. When authentication logic is implemented without strict validation and secure defaults, it can expose endpoints that leak session identifiers or accept malformed credentials.

Common patterns that lead to Broken Authentication include:

• Storing plaintext or weakly hashed passwords in Mongodb collections, making offline password cracking feasible if the database is compromised.
• Using predictable or missing session tokens, enabling session fixation or hijacking when tokens are passed in URLs or non-HttpOnly cookies.
• Failing to enforce rate limiting on authentication endpoints, which permits credential stuffing or brute-force attacks against user accounts.
• Incorrectly handling user-supplied input in Actix extractors (e.g., web::Json<Login>) without strict schema validation, allowing attackers to bypass checks via malformed JSON or unexpected fields.
• Mixing authentication concerns across multiple handlers without a centralized policy, leading to inconsistent checks such as missing HTTPS enforcement or improper CORS configuration that exposes tokens to unauthorized origins.

Because middleBrick scans the unauthenticated attack surface, it can identify these issues by correlating runtime behavior with OpenAPI specifications and observed responses. For example, an endpoint that accepts a wide range of HTTP methods or returns different status codes for invalid credentials may indicate inconsistent authentication handling. The tool also checks whether sensitive data exposure occurs during authentication flows, such as tokens or passwords appearing in logs or error messages, which can compound the risk when paired with weak Mongodb storage practices.

When combined with the LLM/AI Security checks available in middleBrick, the scanner can probe for prompt injection or system prompt leakage that might occur if authentication logic is described in prompts or logs, further highlighting insecure design decisions across the stack.

Secure authentication with Actix and Mongodb requires strict handling of credentials, tokens, and session state. Below are concrete, working code examples that align with the 12 security checks performed by middleBrick.

1. Secure password storage with hashing

Never store passwords in plaintext. Use a strong adaptive hash such as Argon2id. The following example shows a Mongodb document structure and how to store and verify passwords safely within an Actix handler.

use mongodb::{bson::{doc, oid::ObjectId, Document}, Client};
use argon2::{Argon2, PasswordHash, PasswordHasher, PasswordVerifier};
use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize, Serialize)]
struct User {
    #[serde(rename = "_id", skip_serializing_if = "Option::is_none")]
    id: Option,
    username: String,
    password_hash: String,
}

async fn create_user(client: &Client, username: &str, password: &str) -> Result<(), mongodb::error::Error> {
    let argon2 = Argon2::default();
    let hash = argon2.hash_password(password.as_bytes(), &argon2::Config::default())?.to_string();
    let user = User {
        id: None,
        username: username.to_string(),
        password_hash: hash,
    };
    let coll = client.database("authdb").collection("users");
    coll.insert_one(user, None).await?;
    Ok(())
}

async fn verify_user(client: &Client, username: &str, password: &str) -> Result {
    let coll = client.database("authdb").collection("users");
    let filter = doc! { "username": username };
    let user: Option = coll.find_one(filter, None).await?;
    match user {
        Some(u) => {
            let parsed = PasswordHash::new(&u.password_hash).map_err(|_| {
                mongodb::error::Error::from(std::io::Error::new(std::io::ErrorKind::InvalidData, "invalid hash"))
            })?;
            let argon2 = Argon2::default();
            Ok(argon2.verify_password(password.as_bytes(), &parsed).is_ok())
        }
        None => Ok(false),
    }
}

2. Rate limiting and input validation in Actix extractors

Use Actix middleware or guards to enforce rate limits on authentication endpoints and validate input strictly. This reduces the risk of brute-force attacks and ensures that malformed payloads are rejected early.

use actix_web::{web, HttpRequest, HttpResponse, Error};
use std::time::{SystemTime, UNIX_EPOCH};

async fn login_handler(
    creds: web::Json<Login>,
    req: HttpRequest,
) -> Result<HttpResponse, Error> {
    // Basic input validation
    if creds.username.is_empty() || creds.password.is_empty() {
        return Ok(HttpResponse::BadRequest().json(serde_json::json!({
            "error": "missing credentials"
        })));
    }
    // Rate limiting: simplistic timestamp-based guard (use a crate like actix-web-ratelimit in production)
    let now = SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs();
    // Assume a rate limiter state stored elsewhere
    if is_rate_limited(&req, now) {
        return Ok(HttpResponse::TooManyRequests().json(serde_json::json!({
            "error": "rate limit exceeded"
        })));
    }
    // Proceed with authentication logic
    Ok(HttpResponse::Ok().json(serde_json::json!({ "status": "ok" })))
}

fn is_rate_limited(_req: &HttpRequest, _now: u64) -> bool {
    // Placeholder: integrate with Redis or in-memory store
    false
}

#[derive(serde::Deserialize)]
struct Login {
    username: String,
    password: String,
}

3. Secure session tokens and cookie attributes

If using token-based authentication, store tokens securely and avoid leaking them via URLs or logs. Configure cookie attributes to prevent client-side script access and enforce secure transmission.

use actix_web::cookie::{Cookie, SameSite};
use actix_web::HttpResponse;

fn set_auth_cookie(resp: HttpResponse, token: &str) -> HttpResponse {
    resp.cookie(
        Cookie::build(("auth_token", token.to_string()))
            .secure(true)
            .http_only(true)
            .same_site(SameSite::Strict)
            .path("/")
            .finish()
    )
}

These examples align with middleBrick checks for Authentication, BOLA/IDOR, Input Validation, and Data Exposure. By combining secure storage, strict validation, and hardened cookie policies, you reduce the attack surface that middleBrick would otherwise flag with high severity findings.