Api Key Exposure in Rocket with Hmac Signatures

When Rocket routes handle API keys and the service uses Hmac Signatures for request authentication, exposure can occur if keys are transmitted or logged in a way that bypasses the Hmac protection. A common pattern in Rocket is to read an API key from request headers (e.g., X-API-Key) and then compute an Hmac over the request components (method, path, selected headers, and body) using a shared secret. If the API key itself is included in the signed payload or echoed in logs, and if the key is transmitted without additional transport protections, an attacker who can observe requests may learn the key directly despite the Hmac being present.

In Rocket, if you define a fairing or request guard that extracts the API key and also includes it in data that is Hmac-signed, you risk exposing the key in environments where request inspection is possible (for example, through compromised logging, debugging output, or intermediary proxies). Hmac Signatures ensure integrity and authenticity of a request, but they do not prevent an exposed key from being captured if that key is transmitted or stored insecurely. For instance, logging the raw header value or including the key in a debug payload effectively bypasses the integrity guarantee because the key becomes an observable secret. An attacker who captures both the Hmac signature and the exposed key could potentially replay requests or, if key rotation is not enforced, maintain long-term access.

Another vector specific to Rocket’s type-driven routing and request guards is mismatched expectations between what is signed and what is transmitted. If the Hmac is computed over a subset of headers but the API key is sent as a separate header that is not included in the signature, an attacker can modify or replay the key without invalidating the signature. Conversely, if the key is included in the signature but also logged or returned in error responses, the key is effectively exposed in plaintext alongside a valid signature. This combination can be discovered by scanners that correlate endpoint behavior, logging practices, and the presence of authentication mechanisms, which is why middleBrick’s unauthenticated scans flag such endpoints when they detect that an API key is returned or logged in a way that weakens the Hmac’s purpose.

Example of a risky Rocket implementation that can lead to exposure:

use rocket::{get, State, http::Status};
use rocket::request::{self, FromRequest};
use rocket::data::Data;
use hmac::{Hmac, Mac};
use sha2::Sha256;

type HmacSha256 = Hmac<Sha256>;

struct ApiKey(String);

#[rocket::async_trait]
impl<'r> FromRequest<'r> for ApiKey {
    type Error = ();
    async fn from_request(req: &rocket::Request<'r>) -> request::Outcome<Self, Self::Error> {
        let key = req.headers().get_one("X-API-Key").map(|s| s.to_string());
        match key {
            Some(k) => {
                // Risk: logging the key or including it in diagnostics
                rocket::info!(target: "api_key_log", "Received API key: {}", k);
                request::Outcome::Success(ApiKey(k))
            }
            None => request::Outcome::Failure((Status::Unauthorized, ())),
        }
    }
}

fn compute_hmac(key: &str, message: &str) -> String {
    let mut mac = HmacSha256::new_from_slice(key.as_bytes()).expect("HMAC can take key of any size");
    mac.update(message.as_bytes());
    let result = mac.finalize();
    let code = result.into_bytes();
    hex::encode(code)
}

#[get("/protected")]
fn protected(key: ApiKey) -> String {
    // Risk: using the key both as a secret and exposing it indirectly
    let sig = compute_hmac(&key.0, "GET:/protected");
    format!("sig={}, key_hint={}", sig, &key.0[0..3]) // exposing part of the key
}

In the example, the API key is extracted, logged, and partially exposed in the response. Even though Hmac Signatures are used to sign a message, the key itself is leaked through logs and a truncated response, undermining the security model. middleBrick flags such endpoints because the presence of an API key combined with weak handling increases the chance of inadvertent disclosure.

Remediation focuses on ensuring that API keys are never logged, returned to the client, or included in signed data in a way that reveals them. Keep the key strictly within the Hmac computation and avoid any debug or logging path that exposes it. Use Rocket’s request guards to validate the key and signature without leaking details.

Secure Rocket handler with Hmac that avoids exposing the key:

use rocket::{get, State, http::Status};
use rocket::request::{self, FromRequest};
use rocket::response::status;
use hmac::{Hmac, Mac};
use sha2::Sha256;

type HmacSha256 = Hmac<Sha256>;

struct ApiKey(String);

#[rocket::async_trait]
impl<'r> FromRequest<'r> for ApiKey {
    type Error = ();
    async fn from_request(req: &rocket::Request<'r>) -> request::Outcome<Self, Self::Error> {
        let key = req.headers().get_one("X-API-Key").map(|s| s.to_string());
        match key {
            Some(k) => request::Outcome::Success(ApiKey(k)),
            None => request::Outcome::Failure((Status::Unauthorized, ())),
        }
    }
}

fn compute_hmac(key: &str, message: &str) -> String {
    let mut mac = HmacSha256::new_from_slice(key.as_bytes()).expect("HMAC can take key of any size");
    mac.update(message.as_bytes());
    let result = mac.finalize();
    let code = result.into_bytes();
    hex::encode(code)
}

#[get("/protected")]
fn protected(key: ApiKey, req: &rocket::Request) -> Result<String, status::Unauthorized<()>> {
    // Build the message exactly as in the signature verification side
    let message = format!("{}:{}", req.method(), req.uri().path());
    let expected_sig = compute_hmac(&key.0, &message);

    // Obtain client signature from header (e.g., X-Request-Signature)
    let client_sig = match req.headers().get_one("X-Request-Signature") {
        Some(s) => s,
        None => return Err(status::Unauthorized(())),
    };

    // Constant-time comparison to avoid timing leaks
    if subtle::ConstantTimeEq::ct_eq(expected_sig.as_bytes(), client_sig.as_bytes()).into() {
        // Do not echo the key anywhere; return only necessary business data
        Ok("access granted".to_string())
    } else {
        Err(status::Unauthorized(()))
    }
}

Key remediation points:

• Never log the API key or include it in responses, even partially.
• Compute the Hmac over a canonical message (method + path, and optionally selected headers/body) and verify on the server without exposing the key.
• Use constant-time comparison to avoid timing side-channels.
• Ensure the key is transmitted with TLS and not included in URLs or query parameters where it may be logged.
• Rotate keys regularly and avoid using the same key for multiple purposes; this limits exposure if a single signature or log is compromised.

By aligning the signing process with secure handling of the secret and removing any debug output, the combination of Rocket routes and Hmac Signatures can provide strong integrity and authenticity without inadvertently exposing the key itself.

• Does including the API key in the Hmac signature protect it from exposure?

  No. Hmac Signatures ensure that a request has not been tampered with, but if the key itself is transmitted in headers that are logged, echoed in errors, or visible to intermediaries, it can still be exposed. The signature does not hide the key; it only validates the request integrity.

• How does middleBrick detect risky combinations of API key exposure and Hmac Signatures?

  During unauthenticated scans, middleBrick checks whether endpoints return or leak API keys in responses, logs, or debug data, and correlates this with the presence of authentication mechanisms. It flags cases where keys are exposed in a way that undermines the security guarantees provided by Hmac Signatures, giving prioritized findings with remediation guidance.