Dns Rebinding in Actix with Firestore

DNS Rebinding is a client-side attack that manipulates DNS responses to make a browser believe a remote host is local. When an Actix-based web application embeds Firestore client initialization via frontend JavaScript, the combination can expose a security boundary bypass if the application relies on hostnames for Firestore endpoint resolution without additional safeguards.

Actix is a Rust web framework often used to serve frontend assets and API routes. If an Actix server serves a page that initializes Firestore using a hostname-controlled configuration (e.g., a subdomain or CNAME that resolves to an internal or attacker-controlled IP), an attacker can use DNS Rebinding to make the browser send requests to internal Firestore endpoints that the browser would normally treat as out-of-origin.

During a scan, middleBrick tests this by checking whether the application exposes sensitive Firestore REST endpoints and whether CORS and referrer policies are restrictive enough to prevent cross-origin manipulation. Firestore rules are not a network boundary; they are authorization mechanisms. If the client initializes Firestore with a project ID and a hostname that can be rebinding, the browser may send requests that bypass intended origin checks, potentially leading to insecure exposure of Firestore REST endpoints to a malicious page.

middleBrick’s LLM/AI Security checks do not apply here, but its unauthenticated scan detects whether Firestore-related endpoints are reachable from the tested origin and whether the application sets restrictive HTTP headers (such as Content-Security-Policy and Referrer-Policy) that mitigate rebinding risks. The scanner also flags missing origin validation on any backend routes in Actix that proxy or forward requests to Firestore, which could otherwise be abused in a chained attack.

To mitigate DNS Rebinding risks when integrating Firestore with an Actix application, focus on server-side controls and strict frontend initialization. Do not rely on network-level blocking alone; enforce origin checks and initialize Firestore with explicit configuration that is not dynamically derived from DNS-controlled values served to the browser.

1. Serve static assets with restrictive headers

Ensure your Actix static file handler sets strong CSP and Referrer-Policy headers to limit which origins can execute scripts and embed your resources.

use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use actix_web::http::header;

async fn index() -> impl Responder {
    HttpResponse::Ok()
        .content_type("text/html; charset=utf-8")
        .insert_header((
            header::CONTENT_SECURITY_POLICY,
            "default-src 'self'; script-src 'self' https://apis.google.com; object-src 'none'",
        ))
        .insert_header((header::REFERER_POLICY, "strict-origin-when-cross-origin"))
        .insert_header((header::X_CONTENT_TYPE_OPTIONS, "nosniff"))
        .body(include_str!("../static/index.html"))
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .route("/", web::get().to(index))
            .service(actix_files::Files::new("/static", "./static"))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

This CSP restricts script sources to same-origin and Google-hosted APIs used by Firestore, mitigating unauthorized script execution from rebinded origins.

2. Initialize Firestore with explicit configuration on the client

On the frontend, avoid deriving project configuration from environment variables that can be influenced by DNS. Use hardcoded or build-time-injected values, and ensure the Firestore client is initialized with explicit API endpoints that are not subject to hostname manipulation at runtime.

<script src="https://www.gstatic.com/firebasejs/9.23.0/firebase-app-compat.js"></script>
<script src="https://www.gstatic.com/firebasejs/9.23.0/firebase-firestore-compat.js"></script>
<script>
  const firebaseConfig = {
    apiKey: "AIzaSyD_example_key_for_education",
    authDomain: "myproject-12345.firebaseapp.com",
    projectId: "myproject-12345",
    storageBucket: "myproject-12345.appspot.com",
    messagingSenderId: "1234567890",
    appId: "1:1234567890:web:abc123def456"
  };
  firebase.initializeApp(firebaseConfig);
  const db = firebase.firestore();
</script>

By pinning authDomain and projectId, you reduce the risk that a rebinded hostname will cause the client to initialize Firestore against a rogue project or endpoint. Note that these keys are still public and should be protected with App Check and strict Firestore rules on the backend.

3. Validate origins on any Actix backend proxies

If your Actix service acts as a proxy to Firestore REST APIs, validate the Origin header and reject requests with unexpected referrers. Do not forward requests solely based on path patterns.

use actix_web::{dev::ServiceRequest, Error, HttpMessage};
use actix_web::http::header::ORIGIN;

fn validate_origin(req: &ServiceRequest) -> Result<(), Error> {
    if let Some(origin) = req.headers().get(ORIGIN) {
        if let Ok(origin_str) = origin.to_str() {
            if origin_str == "https://myapp.example.com" {
                return Ok(());
            }
        }
    }
    Err(actix_web::error::ErrorForbidden("Invalid origin"))
}

This ensures that only requests from your trusted frontend origin are proxied, reducing the attack surface for rebinding or cross-origin data access.

middleBrick’s dashboard can help track these headers and flagged endpoints over time. For teams needing deeper integration, the CLI (middlebrick scan <url>) and GitHub Action can enforce security thresholds in CI/CD, while the MCP Server allows scanning APIs directly from AI-assisted development environments.