Dns Rebinding in Flask with Firestore

DNS Rebinding is a network-based attack where an attacker circumvents same-origin policy controls by rapidly changing the IP address of a domain name after a victim’s browser resolves it. In a Flask application that integrates with Google Cloud Firestore, this can expose sensitive backend endpoints and Firestore operations to a malicious actor on the network.

Consider a Flask service that exposes an internal route to fetch user documents from Firestore. If this route does not enforce strict host-based validation and relies solely on origin checks performed by the browser, an attacker on the same network can use a DNS Rebinding tool (such as dnsserver with a custom resolver) to make the browser send requests to the internal IP address of the Flask app. Because the browser’s same-origin policy is based on the domain name, not the resolved IP, the request may include cookies or tokens that were issued for the public domain but are now being sent to an internal endpoint.

When the Flask app forwards these requests to Firestore using the Admin SDK or a service account–bound client, the attacker may be able to trigger operations that would otherwise be restricted to backend contexts. For example, a route like /api/user/profile that uses the Firestore client to read a user’s private data could be invoked by the attacker’s rebinding request. If the Flask app does not re-validate the request origin or enforce strict referrer checks, the Firestore read may succeed from the attacker’s machine, leaking private documents.

Additionally, if the Flask app exposes endpoints that modify Firestore data (writes, deletions, or batch updates) and these endpoints are not protected against Cross-Site Request Forgery (CSRF) or do not enforce strict CORS policies, a DNS Rebinding attack can chain a read operation with a write operation. The attacker crafts a page that causes the victim’s browser to first resolve to the public domain (passing CORS), then rebind to the internal Flask host and issue a state-changing Firestore request. Because the browser automatically includes session cookies, the Flask app may treat the request as legitimate.

In this context, middleBrick’s unauthenticated scan can surface such risks by testing the exposed attack surface of the Flask endpoint. It checks for CORS misconfigurations, missing host-header validation, and signs of overly permissive routing that could facilitate rebinding. The scanner does not exploit the vulnerability but highlights where controls are weak, enabling developers to apply targeted remediation before an attacker on the network weaponizes the chain.

To mitigate DNS Rebinding in a Flask application using Firestore, you must combine network-aware request validation with secure Firestore client usage. The following practices and code examples illustrate concrete defenses.

1. Enforce strict host and origin validation

Always validate the Host header and the Origin header on incoming requests. Do not rely on the browser’s same-origin policy for backend security. In Flask, use a before-request handler to reject requests that do not match an allowlist of expected domains and hostnames.

from flask import Flask, request, abort

app = Flask(__name__)

ALLOWED_HOSTS = {"api.yourapp.com", "www.yourapp.com"}
ALLOWED_ORIGINS = {"https://www.yourapp.com", "https://app.yourapp.com"}

@app.before_request
def enforce_host_and_origin():
    host = request.headers.get("Host", "")
    origin = request.headers.get("Origin", "")
    if host not in ALLOWED_HOSTS:
        abort(403, "Host not allowed")
    if origin and origin not in ALLOWED_ORIGINS:
        abort(403, "Origin not allowed")

2. Use explicit CORS configuration

Do not use broad CORS rules like Access-Control-Allow-Origin: *. Configure CORS to allow only specific origins and methods. For Flask, the flask-cors extension provides a straightforward way to enforce this.

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app, resources={
    r"/api/*": {
        "origins": ["https://www.yourapp.com"],
        "methods": ["GET", "POST"],
        "allow_headers": ["Content-Type", "Authorization"],
        "supports_credentials": True
    }
})

3. Validate and sanitize all inputs before Firestore operations

Never trust path parameters or query strings. Use strict validation and map validated inputs to Firestore document IDs or collection names. Below is an example of safely reading a user profile document using the Firestore Python client.

from flask import Flask, jsonify, request
from google.cloud import firestore
import re

app = Flask(__name__)
db = firestore.Client()

USER_ID_REGEX = re.compile(r"^[a-zA-Z0-9_-]{1,100}$")

@app.route("/api/user/", methods=["GET"])
def get_user_profile(user_id):
    if not USER_ID_REGEX.match(user_id):
        abort(400, "Invalid user ID")
    doc_ref = db.collection("users").document(user_id)
    doc = doc_ref.get()
    if not doc.exists:
        abort(404, "User not found")
    return jsonify({user_id: doc.to_dict()})

4. Avoid exposing sensitive operations via unauthenticated routes

If an endpoint performs privileged Firestore operations (e.g., admin queries or batch writes), require authentication and enforce role-based checks. Do not assume that network-level isolation is sufficient when DNS Rebinding is possible.

from flask import g

def require_auth(f):
    def wrapper(*args, **kwargs):
        if not getattr(g, "user", None):
            abort(401, "Authentication required")
        return f(*args, **kwargs)
    return wrapper

@app.route("/api/admin/audit", methods=["GET"])
@require_auth
def audit_log():
    if g.user.get("role") != "admin":
        abort(403, "Insufficient permissions")
    docs = db.collection("audit").order_by("timestamp", direction=firestore.Query.DESCENDING).stream()
    return jsonify([{"id": doc.id, **doc.to_dict()} for doc in docs])

5. Use short-lived tokens and avoid long-lived session cookies for sensitive actions

Where possible, issue short-lived access tokens for API interactions and require re-authentication for critical Firestore operations. This reduces the window in which a rebinding attack can leverage stolen cookies.

middleBrick can be used to validate these defenses by scanning your Flask endpoints and surfacing CORS, host-header, and input validation issues. Its checks align with the OWASP API Top 10 and can help you prioritize fixes for classes of vulnerabilities like DNS Rebinding and related injection paths.