Clickjacking in Rocket with Mutual Tls

Clickjacking is a client-side web vulnerability where an attacker tricks a user into interacting with invisible or disguised UI elements inside an iframe. In a Rocket application that uses Mutual TLS (mTLS), the presence of client certificate authentication does not prevent clickjacking. mTLS ensures the client presenting a valid certificate is the one initiating the request, but it does not restrict how the response is rendered or embedded by the browser. If a Rocket endpoint serves HTML that is missing anti-clickjacking defenses, an attacker can embed that page in an iframe and overlay interactive controls, leading to unauthorized actions despite mTLS being in place.

Mutual TLS is typically enforced at the transport layer by the server requesting and validating a client certificate. In Rocket, this can be implemented via a TLS acceptor that requires client authentication. However, this enforcement applies to the request, not to the response headers that govern framing. An mTLS-protected endpoint that returns sensitive UI without X-Frame-Options or Content-Security-Policy (CSP) frame-ancestors is still susceptible to clickjacking. The combination therefore exposes a false sense of security: authentication is strong, but the UI surface remains exploitable if framing controls are omitted.

Consider a Rocket handler that returns a form to confirm a financial transaction, protected by mTLS. An authenticated user’s browser could load the attacker’s page, which embeds the transaction form in a hidden iframe. The user might inadvertently submit the form by interacting with elements on the attacker’s site. Because the browser sends the client certificate automatically as part of the same origin request, the server processes the transaction as valid. middleBrick would flag this as a missing framing policy in the Security Header checks, noting that mTLS does not mitigate UI redressing risks.

Real-world attack patterns align with this scenario. For example, CVE-2020-11975 involved clickjacking against admin panels where missing CSP frame-ancestors allowed unauthorized actions. Although that specific case did not involve mTLS, the principle holds: transport-layer authentication does not replace content-level framing controls. The OWASP API Security Top 10 and related browser security guidelines emphasize that defenses must be applied at the response level regardless of authentication strength.

Remediation focuses on ensuring that responses served over mTLS-protected connections include explicit framing restrictions. In Rocket, you can set headers globally or per route to prevent embedding. Below are concrete, syntactically correct examples using stable Rocket patterns.

Global security headers with managed routes

Define a fairing or managed state to attach security headers to relevant responses. This example uses Rocket’s request guards and response guards to ensure headers are present for routes that require mTLS.

use rocket::{http::Header, response::Response};
use rocket::request::{self, FromRequest, Request};
use rocket::Outcome;

// Example guard that represents mTLS client validation (simplified).
struct MtlsClient(String);

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

    async fn from_request(req: &'r Request<'_>) -> request::Outcome {
        // In real usage, validate the client certificate from the TLS context.
        // This placeholder demonstrates the pattern.
        if let Some(cert) = req.headers().get_one("x-client-cert") {
            Outcome::Success(MtlsClient(cert.to_string()))
        } else {
            Outcome::Failure((Status::Unauthorized, ()))
        }
    }
}

// Attach security headers for routes that use mTLS.
#[rocket::get("/secure")]
async fn secure_route(_client: MtlsClient) -> &'static str {
    "This response is protected by mTLS and framing controls."
}

// Fairing to add headers to responses.
struct SecurityHeaders;

#[rocket::async_trait]
impl<'r> rocket::fairing::Fairing for SecurityHeaders {
    fn info(&self) -> rocket::fairing::Info {
        rocket::fairing::Info {
            name: "Security Headers",
            kind: rocket::fairing::Kind::Response,
        }
    }

    async fn on_response<'r>(&self, _request: &'r Request<'_>, response: &mut Response<'_>) {
        response.set_header(Header::new("X-Frame-Options", "DENY"));
        response.set_header(Header::new(
            "Content-Security-Policy",
            "frame-ancestors 'none'",
        ));
    }
}

#[rocket::main]
async fn main() -> rocket::Result<()> {
    rocket::build()
        .attach(SecurityHeaders)
        .mount("/", routes![secure_route])
        .launch()
        .await
}

Per-route header attachment with response builder

If you prefer to set headers directly in the handler, use Rocket’s Response builder to ensure framing controls are applied consistently.

use rocket::http::Status;
use rocket::response::Response;
use rocket::Request;

#[rocket::get("/transaction")]
async fn transaction() -> Result<Response, Status> {
    let mut response = Response::build();
    response.set_header(rocket::http::Header::new("X-Frame-Options", "SAMEORIGIN"));
    response.set_header(rocket::http::Header::new(
        "Content-Security-Policy",
        "frame-ancestors 'self'",
    ));
    response.ok()
}

Complementary measures

While mTLS handles authentication, combine it with the above headers to create a defense-in-depth approach. Use X-Frame-Options: DENY or Content-Security-Policy: frame-ancestors 'none' to explicitly prohibit framing. These settings ensure that even if an mTLS-authenticated session exists, the page cannot be embedded in an attacker’s site, effectively mitigating clickjacking.