Prototype Pollution in Actix with Hmac Signatures

Prototype pollution in Actix applications that use Hmac signatures can arise when user-controlled input influences object properties before signature validation or after signature verification but before safe serialization. In this context, pollution is not about tampering with the signature itself, but about manipulating object properties that affect runtime behavior, logging, or downstream processing after the request has been authenticated. For example, an endpoint might deserialize JSON into a Rust struct, apply business logic, and then serialize back to JSON. If the deserialization is permissive (e.g., using serde_json::Value or a dynamically built map) and the application later iterates over keys to construct a response or a log entry, an attacker can inject properties like __proto__, constructor, or other special keys that alter behavior in JavaScript-like contexts or in unsafe Rust code that relies on property enumeration.

When Hmac signatures are involved, a common pattern is to sign a canonical representation of the payload—such as a sorted key-value concatenation or a hash of the raw body—to ensure integrity. If the application normalizes or parses the payload into a mutable object before computing the Hmac, and that object is susceptible to prototype pollution, an attacker may attempt to inject properties that affect the canonical form. However, because Hmac is computed over bytes, direct mutation of a JavaScript-style prototype chain is not possible in safe Rust; the risk is instead that pollution occurs in the application’s internal data model (e.g., a HashMap or a serde_json::Map) that is later used to reconstruct a response or to make authorization decisions. For instance, an attacker might supply a parameter such as ?redirect_url[__proto__]=http://evil.com in a query string that is merged into a map before signature verification. If the server uses this map to generate a redirect or to format a JSON response, the poisoned property can cause unexpected behavior, such as modifying inherited properties in downstream JavaScript code or triggering type confusion in unsafe deserialization routines.

Another angle involves logging and observability. Actix applications often log request metadata, including headers or query parameters, to aid debugging. If these logs are later consumed by tools that evaluate object properties—such as a security monitoring dashboard that parses JSON logs—polluted keys can cause incorrect grouping, false positives, or even code execution if the evaluation context is unsafe. Because Hmac signatures ensure that the payload has not been altered in transit, developers may assume that logged data is trustworthy. However, prototype pollution does not break the signature; it exploits the application’s handling of structured data after verification. Therefore, the combination of Hmac-based integrity checks and permissive object manipulation creates a subtle gap where security relies on careful normalization and strict schema enforcement rather than on the signature alone.

Remediation focuses on strict input validation, canonical representation, and avoiding mutable merging of user-controlled data before Hmac computation. In Actix, you should treat all external input as untrusted and normalize it before including it in the signed payload. Use strongly typed structs with serde’s deny_unknown_fields to prevent unexpected properties from being deserialized. This ensures that prototype-like keys such as __proto__ or constructor are rejected during deserialization rather than being silently stored in a map.

When computing Hmac signatures, work with a canonical byte representation that does not depend on dynamic object traversal. For example, serialize the relevant fields into a deterministic format—such as sorted key-value pairs in JSON or a fixed binary layout—before applying the Hmac algorithm. This minimizes the risk that variations in object shape affect the signature. Below is a concrete example using the hmac and sha2 crates with Actix web, where the signature is computed over a normalized JSON object that excludes any attacker-controlled keys that could introduce pollution.

use actix_web::{web, HttpResponse, Result};
use hmac::{Hmac, Mac};
use sha2::Sha256;
use serde_json::{json, Value};
use std::collections::BTreeMap;

type HmacSha256 = Hmac;

fn compute_signature(payload: &Value, secret: &[u8]) -> String {
    // Canonical representation: sort keys and exclude metadata fields
    let mut map = BTreeMap::new();
    if let Value::Object(obj) = payload {
        for (k, v) in obj {
            // Explicitly block keys that could lead to prototype pollution
            if k == "__proto__" || k == "constructor" || k == "prototype" {
                continue;
            }
            map.insert(k.clone(), v.to_string());
        }
    }
    let canonical = serde_json::to_string(&map).expect("Failed to serialize");
    let mut mac = HmacSha256::new_from_slice(secret).expect("Hmac can take key of any size");
    mac.update(canonical.as_bytes());
    let result = mac.finalize();
    hex::encode(result.into_bytes())
}

async fn handle_request(form: web::Json, secret: web::Data>) -> Result {
    let signature = form.get("signature")
        .and_then(|v| v.as_str())
        .unwrap_or("");
    let data = &form;

    // Remove signature before canonicalization
    let mut data_without_sig = data.as_object().unwrap().clone();
    data_without_sig.remove("signature");
    let data_value = Value::Object(data_without_sig);

    let expected = compute_signature(&data_value, &secret);
    if subtle::ConstantTimeEq::ct_eq(signature.as_bytes(), expected.as_bytes()).into() {
        HttpResponse::Ok().json(json!({ "status": "ok" }))
    } else {
        HttpResponse::Unauthorized().json(json!({ "error": "invalid signature" }))
    }
}

In this example, the server explicitly excludes dangerous keys during canonicalization and uses a BTreeMap to enforce a deterministic order. The Hmac is computed over the cleaned representation, ensuring that prototype-polluting keys never influence the signature or downstream processing. For production use, consider integrating this logic into Actix extractors or middleware so that validation occurs before routing. Additionally, apply the same discipline when constructing responses: avoid dynamically inserting user-controlled keys into objects that may be serialized later. If you need automated security checks in your pipeline, the middleBrick CLI allows you to scan endpoints from the terminal with middlebrick scan <url>, while the GitHub Action can add API security checks to your CI/CD pipeline and fail builds if risk scores drop below your chosen threshold.

After implementing remediation, you can validate your endpoints using the middleBrick Web Dashboard to track security scores over time, or run the middleBrick CLI to scan APIs directly from your terminal. For automated checks in development, the GitHub Action adds API security checks to your CI/CD pipeline, and the MCP Server lets you scan APIs directly from your AI coding assistant within the IDE.