Clickjacking in Actix with Hmac Signatures

Clickjacking relies on tricking a user into interacting with a hidden or disguised UI element inside an embedded frame. In Actix applications, embedding an endpoint inside an iframe is common when building embedded dashboards, third‑party integrations, or widget panels. If the application embeds content without anti‑frame protections and also uses Hmac Signatures only for request authentication (for example to sign query parameters or a JSON body), the signature may not protect the rendered page’s UI actions because the attacker can still load the page in a frame, overlay invisible controls, and relay the signed request through the victim’s browser.

Consider an Actix endpoint that performs a sensitive action (like changing an email) and validates an Hmac Signature in a header or query parameter to ensure the request originates from a trusted source. An attacker can craft a malicious page that loads https://api.example.com/email/change?user=123&action=remove with a valid Hmac, inside a transparent iframe positioned over a benign page. Because the browser sends cookies (including session tokens if present) and the signed parameters, the server may process the action despite the UI being hijacked. The Hmac Signature here ensures integrity of parameters but does not prevent the response from being rendered inside a frame or stop the browser from automatically sending authentication cookies, enabling the clickjacking vector.

In this context, Hmac Signatures alone do not mitigate clickjacking because they do not enforce how the response is displayed or embedded. The signature may be validated successfully, but the UI intent is compromised if the page is framed without safeguards. This is especially relevant when endpoints return HTML that can be framed, or when JSON APIs are consumed by embedded front‑ends that do not enforce frame‑ancestors policy. The server must explicitly prevent framing and ensure that UI actions cannot be transparently triggered by an attacker, even when the request carries a valid Hmac.

To remediate clickjacking in Actix while using Hmac Signatures, combine frame‑level defenses with strict signature validation and secure cookie practices. Use the X-Frame-Options header or Content-Security-Policy frame‑ancestors directive to prevent the response from being embedded. Ensure Hmac verification is applied consistently and that cookies are scoped with SameSite and Secure attributes to reduce the risk of cross‑site request forgery (CSRF) complementing clickjacking attacks.

Below are concrete Actix examples that show how to implement Hmac verification and frame protection together.

Hmac verification middleware in Actix

use actix_web::{dev::ServiceRequest, Error, HttpResponse};
use actix_web_httpauth::extractors::header::Authorization;
use hmac::{Hmac, Mac};
use sha2::Sha256;

type HmacSha256 = Hmac;

async fn verify_hmac(req: ServiceRequest) -> Result {
    // Extract signature from header or query
    let headers = req.headers();
    let signature = headers.get("X-Signature")
        .and_then(|v| v.to_str().ok())
        .ok_or_else(|| actix_web::error::ErrorUnauthorized("Missing signature"))?;

    let payload = req.payload::().map_err(|_| actix_web::error::ErrorBadRequest("no payload"))?;
    let secret = std::env::var("HMAC_SECRET").expect("HMAC_SECRET must be set");

    let mut mac = HmacSha256::new_from_slice(secret.as_bytes())
        .map_err(|_| actix_web::error::ErrorInternalServerError("Hmac init failed"))?;
    mac.update(payload.as_bytes());
    let computed = mac.finalize();
    let code = computed.into_bytes();

    // Constant-time comparison
    if subtle::ConstantTimeEq::ct_eq(&code[..], hex::decode(signature).unwrap_or_default().as_slice()).into() {
        Ok(req)
    } else {
        Err(actix_web::error::ErrorUnauthorized("Invalid signature"))
    }
}

In this snippet, the Hmac is computed over the request payload using a secret and compared in constant time. Apply this check to state‑changing endpoints (POST, PUT, DELETE). For GET endpoints that render HTML, ensure the response headers prevent framing.

Frame protection and secure cookies in Actix responses

use actix_web::{web, HttpResponse, Responder};

async fn change_email_form() -> impl Responder {
    HttpResponse::Ok()
        .insert_header(("X-Frame-Options", "DENY"))
        .insert_header(("Content-Security-Policy", "frame-ancestors 'none'"))
        .cookie(
            actix_web::cookie::Cookie::build(("session", "value"))
                .http_only(true)
                .secure(true)
                .same_site(actix_web::cookie::SameSite::Strict)
                .finish()
        )
        .body(include_str!("change_email.html"))
}

The response headers explicitly deny framing, and the session cookie is marked HttpOnly, Secure, and SameSite=Strict. This combination reduces the window for clickjacking even if the client’s browser does not enforce Hmac-based intent protection. For SPAs or API‑driven front‑ends, ensure that sensitive actions require both a valid Hmac Signature and a non‑frameable response, and consider requiring a re‑auth step for high‑risk operations.