Information Disclosure in Axum with Api Keys
Information Disclosure in Axum with Api Keys
Information disclosure in Axum applications often occurs when API keys are handled without adequate safeguards, exposing secrets through logs, error messages, or misconfigured routes. Axum, a Rust web framework, does not inherently leak keys, but developer patterns can inadvertently surface them in HTTP responses or server-side logs.
Consider an Axum handler that echoes headers for debugging:
use axum::{headers::Authorization, routing::get, Router};
use std::net::SocketAddr;
async fn debug_handler(authorization: OptionIf this endpoint is exposed publicly, an attacker can send requests with a valid API key in the Authorization header and receive the key back in the response. This is a clear information disclosure: the secret is reflected directly, bypassing any intended access control.
Another common pattern involves logging API keys for tracing or monitoring. For example:
use tracing::info;
fn call_service(api_key: &str) -> Result<(), reqwest::Error> {
info!(api_key = %api_key, "Calling external service");
// ... make request
Ok(())
}
Storing API keys in structured logs places them at risk of exposure through log aggregation systems or unauthorized log access. In Axum applications, middleware that captures request details must explicitly exclude sensitive headers to prevent such disclosure.
A third vector arises from improper OpenAPI/Swagger generation. If an Axum service generates an OpenAPI spec that includes example values containing real API keys, and that spec is served publicly, the secrets are exposed via the /docs endpoint. For instance, a generated spec might contain:
{
"paths": {
"/external": {
"get": {
"parameters": [
{
"name": "Authorization",
"in": "header",
"example": "Bearer sk_live_abc123def456"
}
]
}
}
}
}
This example value, if derived from a real key, becomes a persistent leak in documentation. Axum developers must ensure generated specs use placeholder values and that runtime findings from scans do not include actual keys in error payloads.
Api Keys-Specific Remediation in Axum
Remediation focuses on preventing keys from appearing in responses, logs, or documentation, and on ensuring they are handled as secrets rather than business data.
- Strip sensitive headers before responses: Do not echo Authorization or custom key headers back to the client. Instead, consume them without reflection.
use axum::{routing::get, Router}; async fn no_echo_handler() -> &'static str { // Validate the key via middleware or extractor, but do not return it. "Request processed" } fn build_app() -> Router { Router::new().route("/internal", get(no_echo_handler)) } - Sanitize logging: Use field redaction or filtering to ensure API keys are never written to logs. For example, with
tracing_subscriber, configure a layer that filters sensitive fields:use tracing_subscriber::{layer::SubscriberExt, util::SubscriberInitExt}; use tracing_subscriber::fmt::format::FmtSpan; fn init_logger() { let subscriber = tracing_subscriber::fmt() .json() .with_filter(tracing_subscriber::filter::LevelFilter::INFO) .with_target(false) .finish(); tracing::subscriber::set_global_default(subscriber).expect("setting default subscriber failed"); }Additionally, avoid structured logging of headers. If logging is required, explicitly exclude
authorizationand similar fields. - Protect generated documentation: Ensure OpenAPI specs served by Axum do not contain real keys. Use placeholders and validate that examples do not match production key patterns. A manual check can be added in build scripts to reject commits containing live key patterns in spec files.
These steps align with the checks performed by tools like middleBrick, which scans for information disclosure and flags reflected secrets or risky documentation. The free tier allows initial scans to identify such issues; for ongoing protection, the Pro plan provides continuous monitoring so that new endpoints or changes do not reintroduce key exposure.