Clickjacking in Axum with Api Keys

Clickjacking is a client-side attack that tricks a user into interacting with a hidden or disguised UI element, often by nesting the target application inside an invisible iframe. In Axum applications that expose API keys via UI endpoints or embed keys in JavaScript, clickjacking can expose those keys and enable unauthorized actions. When an Axum app embeds an API key in frontend code or uses key-based authentication to authorize state-changing requests, an attacker can craft a page that loads the Axum UI inside a transparent iframe and overlays interactive controls (e.g., buttons or forms) on top of legitimate key-revealing or key-using endpoints.

Consider an Axum API that returns an API key in a JSON response for a logged-in user and renders that key in a settings page. If the response lacks anti-clickjacking protections, an attacker can embed the endpoint in an iframe and position a transparent button over the key display area. When the user visits the attacker’s page, the user’s browser sends the authenticated request to the Axum app, and the key is revealed through the overlay interaction. Because the request includes the session or key-based credentials, the response may expose the key to the attacker. This pattern is especially dangerous when API keys are used for authorization, since the leaked key can be reused outside the application.

From an API security scan perspective, middleBrick checks for UI-based leakage of secrets and insecure embedding patterns that facilitate clickjacking. The 12 security checks run in parallel and include Data Exposure and Unsafe Consumption analyses, which can surface endpoints that return sensitive data such as API keys without appropriate referrer or frame protections. Because the scan tests the unauthenticated attack surface, it can identify whether responses include keys in JSON or HTML and whether security headers that mitigate clickjacking are absent. Findings include severity ratings and remediation guidance mapped to frameworks such as OWASP API Top 10 and common browser behaviors.

In Axum, the absence of Content-Security-Policy frame-ancestors rules and the presence of sensitive data in API responses are indicators that the application may be vulnerable when combined with clickjacking techniques. Even without authenticated scanning, an attacker can probe endpoints that return API keys and observe whether those responses can be embedded. Defenses must address both the framing behavior and the exposure of keys in API payloads, ensuring that keys are never returned in contexts that can be framed and that responses include appropriate anti-framing headers.

Remediation focuses on two areas: preventing the Axum UI from being framed and ensuring API keys are not exposed in responses that can be triggered via framed contexts. Use the frame-ancestors directive in a Content-Security-Policy header to restrict which origins can embed the page, and avoid returning API keys in HTTP responses that are reachable from embedded UI contexts.

Below are concrete Axum examples that demonstrate secure handling. The first example shows how to set CSP headers to prevent framing and how to structure a handler that avoids exposing API keys in embedded pages.

use axum::{
    async_trait,
    extract::State,
    headers::authorization::Authorization,
    response::{self, IntoResponse, Response},
    routing::get,
    Router,
};
use std::net::SocketAddr;

// Secure handler that does not expose API keys in JSON responses
async fn settings_handler() -> impl IntoResponse {
    // In practice, retrieve the key from a secure vault and use it server-side.
    // Do not serialize the key into the response body.
    let config = serde_json::json!({
        "message": "Settings loaded",
        // Do not include: "api_key": "sk-xxx"
    });
    response::Json(config)
}

// Middleware or wrapper to add security headers
fn with_security_headers(layer: Router) -> Router {
    layer.layer(
        tower_http::trace::TraceLayer::new_for_http(),
    )
    .layer(
        // Example using a custom layer or wrapper to add headers
        // Replace with actual header middleware if available
    )
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/settings", get(settings_handler))
        .into_make_service_with_connect_info::();

    // In production, serve through a reverse proxy or middleware that enforces CSP:
    // Content-Security-Policy: frame-ancestors 'none';
    axum::Server::bind(&"0.0.0.0:3000".parse().unwrap())
        .serve(app)
        .await
        .unwrap();
}

For applications that must return key metadata (not the raw key), ensure the response is not embeddable by setting the CSP frame-ancestors directive to 'none' or to a strict allowlist. Additionally, use the X-Frame-Options header as a legacy safeguard.

use axum::{
    async_trait,
    extract::Extension,
    response::{self, Response},
    routing::get,
    Router,
};
use std::net::SocketAddr;

// Handler that returns non-sensitive metadata only
async fn key_metadata_handler() -> Response {
    let body = serde_json::json!({
        "key_id": "key-123",
        "expires_in": 3600
        // Never include the actual key
    });
    response::Json(body).into_response()
}

// In your main app setup, integrate a middleware that sets headers
// Example pseudo-code: app.layer(add_security_headers())
// Real implementation would use a proper middleware crate.

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/metadata", get(key_metadata_handler))
        .into_make_service_with_connect_info::();

    // Ensure reverse proxy or runtime adds:
    // Content-Security-Policy: frame-ancestors 'none';
    // X-Frame-Options: DENY
    axum::Server::bind(&"0.0.0.0:3000".parse().unwrap())
        .serve(app)
        .await
        .unwrap();
}

When integrating with frontend frameworks, avoid embedding API keys in JavaScript bundles that can be read through framed pages. Instead, use short-lived tokens issued by a secure backend and enforce strict CSP. middleBrick’s scans can validate that endpoints returning sensitive data include frame-protection headers and that API keys are not present in responses that could be triggered via clickjacking vectors.