Missing Authentication in Axum with Basic Auth
Missing Authentication in Axum with Basic Auth — how this specific combination creates or exposes the vulnerability
When an Axum service relies solely on Basic Authentication but does not enforce authentication on one or more endpoints, it exposes a Missing Authentication flaw. This category is part of the 12 parallel security checks in middleBrick, which tests the unauthenticated attack surface to identify endpoints that allow access without valid credentials.
Basic Auth in Axum is typically implemented by inspecting the Authorization header, decoding the base64-encoded username:password pair, and validating credentials. If a route or a group of routes omits this check, an attacker can call those endpoints directly without any credentials. Because Basic Auth credentials are only base64-encoded (not encrypted), sending requests without first validating the header effectively bypasses any intended access control, regardless of whether the credentials themselves are strong.
Consider an API where some routes are intended to be public (e.g., health checks or static configuration), but other routes mistakenly inherit no guard. middleBrick’s authentication checks will flag any endpoint that permits unauthenticated access when other endpoints in the same service require credentials, as this inconsistency can lead to privilege confusion and unauthorized data access. In a real-world scenario, an unauthenticated actor could retrieve sensitive user records, administrative configuration, or operational endpoints that should be restricted.
The scanner also evaluates whether the presence of Basic Auth aligns with transport security. Basic Auth should only be used over TLS; otherwise, credentials are easily decoded in transit. middleBrick checks for encryption (HTTPS) as part of its Encryption category, and when Basic Auth is present without encryption, this compounds the risk by exposing credentials even if authentication itself is implemented.
Because Axum applications can define nested route guards, a developer might believe that applying authentication to a parent router guarantees protection for all children. If a child route overrides or excludes the guard, a Missing Authentication vulnerability can exist. middleBrick’s unauthenticated scanning approach is designed to detect such gaps by attempting to access endpoints without providing any credentials, then analyzing responses for data exposure or unauthorized behavior.
Basic Auth-Specific Remediation in Axum — concrete code fixes
To remediate Missing Authentication in Axum when using Basic Auth, ensure that every route that requires protection validates credentials explicitly and consistently. Below are concrete, working examples that demonstrate secure patterns.
1. Centralized authentication extractor
Define a reusable extractor that validates the Basic Auth header and returns an error if credentials are missing or invalid. This keeps authentication logic consistent across routes.
use axum::{
async_trait,
extract::{FromRequest, Request},
http::{self, StatusCode},
};
use std::convert::Infallable;
use base64::Engine;
pub struct Authenticated;
#[async_trait]
impl FromRequest<S> for Authenticated
where
S: Send + Sync,
{
type Rejection = (StatusCode, String);
async fn from_request(req: Request, _state: &S) -> Result<Self, Self::Rejection> {
let auth_header = req.headers().get(http::header::AUTHORIZATION)
.ok_or((StatusCode::UNAUTHORIZED, "Missing Authorization header".to_string()))?;
let auth_str = auth_header.to_str().map_err(|_| (StatusCode::UNAUTHORIZED, "Invalid header encoding".to_string()))?;
if !auth_str.starts_with("Basic ") {
return Err((StatusCode::UNAUTHORIZED, "Invalid authentication scheme".to_string()));
}
let encoded = auth_str.trim_start_matches("Basic ");
let decoded = base64::engine::general_purpose::STANDARD.decode(encoded)
.map_err(|_| (StatusCode::UNAUTHORIZED, "Invalid base64 encoding".to_string()))?;
let credentials = String::from_utf8(decoded).map_err(|_| (StatusCode::UNAUTHORIZED, "Invalid UTF-8 in credentials".to_string()))?;
let parts: Vec<&str> = credentials.splitn(2, ':').collect();
if parts.len() != 2 {
return Err((StatusCode::UNAUTHORIZED, "Invalid credentials format".to_string()));
}
let (username, password) = (parts[0], parts[1]);
// Validate against your user store or constants
if username == "admin" && password == "s3cureP@ss" {
Ok(Authenticated)
} else {
Err((StatusCode::UNAUTHORIZED, "Invalid username or password".to_string()))
}
}
}
2. Applying authentication selectively and consistently
Use the extractor on routes that must be protected, and avoid omitting it on any handler that deals with sensitive data. Do not rely on route ordering alone to enforce security.
use axum::{routing::get, Router};
async fn public_health() -> &'static str {
"OK"
}
async fn admin_dashboard() -> &'static str {
"Admin Panel"
}
#[tokio::main]
async fn main() {
let app = Router::new()
.route("/health", get(public_health))
.route("/admin/dashboard", get(axum::routing::get(admin_dashboard).layer(axum::middleware::from_fn(|_req, next| async move {
// Ensure authentication is enforced for admin routes
let _auth = Authenticated::from_request(_req).await?;
next.run().await
}))));
axum::Server::bind(&"0.0.0.0:3000".parse().unwrap())
.serve(app.into_make_service())
.await
.unwrap();
}
3. Enforce HTTPS and avoid Basic Auth over plaintext
Always terminate TLS at the edge or load balancer. Configure your server to reject HTTP requests or redirect them to HTTPS. middleBrick will flag Basic Auth without encryption as a high-severity finding in the Encryption category.
By combining a centralized extractor, strict route-level application, and enforced transport security, you eliminate Missing Authentication gaps and ensure that all protected endpoints consistently require valid Basic Auth credentials.
Related CWEs: authentication
| CWE ID | Name | Severity |
|---|---|---|
| CWE-287 | Improper Authentication | CRITICAL |
| CWE-306 | Missing Authentication for Critical Function | CRITICAL |
| CWE-307 | Brute Force | HIGH |
| CWE-308 | Single-Factor Authentication | MEDIUM |
| CWE-309 | Use of Password System for Primary Authentication | MEDIUM |
| CWE-347 | Improper Verification of Cryptographic Signature | HIGH |
| CWE-384 | Session Fixation | HIGH |
| CWE-521 | Weak Password Requirements | MEDIUM |
| CWE-613 | Insufficient Session Expiration | MEDIUM |
| CWE-640 | Weak Password Recovery | HIGH |