Api Key Exposure in Rocket with Bearer Tokens

When Rocket applications expose API keys via Bearer tokens, the risk typically arises from insecure transmission, storage, or logging practices rather than the token type itself. A Bearer token is a simple authentication scheme where the token is sent in the Authorization header as Authorization: Bearer <token>. If Rocket routes or handlers inadvertently leak these headers, or if tokens are embedded in URLs, client-side JavaScript, or logs, the keys become discoverable to unauthorized parties.

In a black-box scan, middleBrick checks whether APIs that accept Bearer tokens transmit them over unencrypted channels or reflect them in error responses. For example, if a Rocket endpoint returns a 401 with the header value echoed back, or if CORS misconfigurations allow cross-origin requests that expose Authorization headers, the scan flags this as Data Exposure. Rocket applications that use logging frameworks which capture full request headers without redaction can also leak tokens into log aggregation systems, creating long-term exposure even when transport is encrypted.

Another vector specific to Rocket involves OpenAPI/Swagger specifications. If an API built with Rocket exposes a spec that includes examples with real Bearer tokens, or if the spec is served publicly without authentication, middleBrick’s OpenAPI analysis detects these references during cross-referencing of spec definitions with runtime findings. This is particularly dangerous when combined with SSRF, where an attacker can use the exposed token to pivot to internal services that trust the same token format.

Additionally, Rocket applications that accept Bearer tokens in query parameters (e.g., ?access_token=xxx) instead of the Authorization header increase exposure risk. Tokens in URLs can be captured in server access logs, browser history, and referrer headers. middleBrick’s Data Exposure checks flag such patterns, especially when tokens appear in GET request examples or when inventory management reveals publicly indexed endpoints that should be authenticated only.

The LLM/AI Security checks add another layer for Rocket APIs that integrate AI features. If a Rocket service forwards Bearer tokens to LLM endpoints or echoes token-related data in model outputs, middleBrick’s active prompt injection probes and output scanning can detect whether sensitive values leak into AI-generated responses. This is critical because misconfigured AI integrations might treat Bearer-like strings as safe to return, inadvertently exposing credentials through chat completions or tool call results.

Finally, Rate Limiting and Unsafe Consumption checks evaluate whether Rocket endpoints that use Bearer tokens enforce proper throttling and input validation. Without these, attackers may probe for valid tokens via brute force or injection, especially if error messages differentiate between missing and invalid tokens. The scanner correlates these findings with the Inventory Management check to highlight endpoints that expose token acceptance without adequate protection.

To remediate Bearer token exposure in Rocket, focus on transmission security, storage hygiene, and output sanitization. Below are concrete code examples aligned with Rocket’s idioms and the 12 security checks run by middleBrick.

1. Always use the Authorization header and HTTPS

Ensure clients send tokens strictly in the Authorization header and never in URLs or cookies. Enforce HTTPS across all Rocket routes.

// Rocket example: validate Bearer token from headers
use rocket::request::{self, FromRequest};
use rocket::http::Status;

struct AuthenticatedUser(String);

#[rocket::async_trait]
impl<'r> FromRequest<'r> for AuthenticatedUser {
    type Error = ();

    async fn from_request(request: &'r request::Request) -> request::Outcome<Self, Self::Error> {
        let auth_header = request.headers().get_one("Authorization");
        match auth_header {
            Some(header) if header.starts_with("Bearer ") => {
                let token = header.trim_start_matches("Bearer ");
                // Validate token format and presence (e.g., check against a secure store)
                if !token.is_empty() {
                    request::Outcome::Success(AuthenticatedUser(token.to_string()))
                } else {
                    request::Outcome::Failure((Status::Unauthorized, ()))
                }
            }
            _ => request::Outcome::Failure((Status::Unauthorized, ())),
        }
    }
}

// Mount routes with fairing to enforce HTTPS
#[rocket::main]
async fn main() {
    rocket::build()
        .mount("/api", routes![secure_endpoint])
        .attach(rocket::fairing::AdHoc::on_ignite(
            "Enforce HTTPS",
            |rocket| async { rocket },
        ))
        .launch()
        .await;
}

2. Redact tokens from logs and error responses

Configure Rocket’s logging to exclude Authorization headers and ensure errors do not reflect token values.

// In Rocket.toml or programmatically, avoid logging headers
// Example: custom logger that filters sensitive headers
use rocket::fairing::{self, Fairing, Info, Kind};

struct SecurityFairing;

impl Fairing for SecurityFairing {
    fn info(&self) -> Info {
        Info { name: "Security Filter", kind: Kind::Response },
    }

    fn on_response(&self, _: &rocket::Request, response: &mut rocket::Response) {
        // Remove or mask sensitive headers before logging
        response.remove_header(rocket::http::Header::new("Authorization", "[REDACTED]"));
    }
}

// Attach in main
// .attach(SecurityFairing)

3. Avoid exposing tokens in OpenAPI specs

Ensure generated OpenAPI documentation does not contain real tokens. Use Rocket’s fairings to sanitize examples.

use rocket::serde::json::Json;
use rocket::http::Header;

#[rocket::get("/openapi.json")]
fn openapi() -> Json<serde_json::Value> {
    // Build spec without example tokens
    let mut spec = json!({ /* your spec */ });
    if let Some(paths) = spec.get_mut("paths") {
        // Remove any example values that resemble tokens
        // This is simplified; in practice, walk the JSON and redact
    }
    Json(spec)
}

4. Validate and sanitize inputs to prevent injection

Even with Bearer tokens, validate all inputs to avoid SSRF and injection that could lead to token leakage.

use rocket::form::Form;

#[derive(FromForm)]
struct SafeParams {
    #[field(validate = len(1..=255))]
    query: String,
}

#[rocket::post("/search", data = <params>)]
fn search(params: Form<SafeParams>) -> String {
    // Process sanitized input
    format!("Search for: {}", params.query)
}

5. Enforce rate limiting and input validation

Use Rocket guards and request limits to reduce token brute-force risk.

use rocket::request::Request;
use rocket::outcome::Outcome;

fn rate_limit(request: &Request) -> Outcome<(), &'static str> {
    // Implement token-bucket or sliding window logic
    Outcome::Success(())
}

// Attach as a request guard or fairing