Open Redirect in Django with Firestore

An open redirect in a Django application that uses Firestore as a backend can occur when a URL parameter is used to construct a redirect response without strict validation. Because Firestore often stores configuration or user-specific data such as allowed redirect URIs, an attacker may manipulate a reference value to point to a malicious host. If the application dynamically builds a redirect using a Firestore document field (for example, a stored return URL) and passes it to Django’s HttpResponseRedirect or redirect shortcut without validation, the redirect can be abused for phishing or client-side manipulation.

Consider a scenario where a user’s allowed redirect URLs are stored in Firestore under a collection user_preferences. If the application retrieves a document field such as redirect_url and uses it directly, an attacker who can tamper with the document (or exploit a lack of ownership checks) may set the field to an external malicious domain. Even if the attacker cannot directly modify the document, a missing check on the referrer or session context can allow an unauthenticated parameter to override the intended destination.

In a black-box scan, middleBrick tests such patterns by probing endpoints that accept a URL parameter, follow redirects, and check whether the final destination can be influenced. Combined with the OpenAPI/Swagger analysis (2.0, 3.0, 3.1) with full $ref resolution, the scanner cross-references spec definitions with runtime behavior to identify whether a redirect path can be steered externally. This is especially relevant when Firestore-backed configuration is used to populate redirect targets, because the spec may not explicitly declare the trust boundaries for dynamic values.

An LLM/AI Security check from middleBrick also looks for system prompt leakage and active prompt injection probes, but for traditional web vulnerabilities like open redirect, the focus remains on input validation and destination control. Without strict allowlisting and server-side validation, even a seemingly benign integration between Django and Firestore can expose a path that enables phishing or loss of user trust.

To remediate an open redirect when using Firestore in Django, enforce server-side allowlisting and avoid using raw user input or untrusted document fields for redirect targets. Validate the resolved destination against a per-session or per-user allowlist stored securely in Firestore, and prefer using named Django URLs with reversed paths rather than raw URLs.

Example: retrieve a user’s allowed redirect target from Firestore, but validate it against a predefined list before redirecting.

import firebase_admin
from firebase_admin import credentials, firestore
from django.http import HttpResponseRedirect
from django.urls import reverse
from django.shortcuts import redirect

cred = credentials.Certificate("path/to/serviceAccountKey.json")
firebase_admin.initialize_app(cred)
db = firestore.client()

def safe_redirect_view(request):
    user_id = request.session.get("user_id")
    next_param = request.GET.get("next")

    # Fetch user preferences from Firestore
    user_ref = db.collection("user_preferences").document(user_id) if user_id else None
    allowed_url = None
    if user_ref:
        doc = user_ref.get()
        if doc.exists:
            allowed_url = doc.to_dict().get("redirect_url")

    # Strict allowlist check
    ALLOWED_HOSTS = ["https://app.example.com/dashboard", "https://app.example.com/settings"]
    destination = None
    if allowed_url and allowed_url in ALLOWED_HOSTS:
        destination = allowed_url
    elif next_param and next_param.startswith("/") and not next_param.startswith("//"):
        # Safe relative path fallback
        destination = next_param
    else:
        destination = reverse("home")  # default safe location

    return HttpResponseRedirect(destination)

In this pattern, the Firestore document field redirect_url is not used directly as the target. Instead, the value is checked against a hardcoded allowlist ALLOWED_HOSTS. If the stored URL does not match, the code falls back to a validated relative path or a named URL reversed via Django’s reverse. This ensures that even if a Firestore document is compromised or misconfigured, the application cannot be forced to redirect to an arbitrary external domain.

For dynamic but controlled scenarios, you can also store full URL paths relative to your domain in Firestore and validate them with urlparse to ensure the netloc matches your domain.

from urllib.parse import urlparse

def is_safe_url(url, allowed_netlocs):
    parsed = urlparse(url)
    return parsed.netloc in allowed_netlocs and url.startswith("https://")

# Usage
if is_safe_url(allowed_url, {"app.example.com"}):
    destination = allowed_url
else:
    destination = reverse("home")

These Firestore-aware validations, combined with Django’s built-in redirect safety practices, reduce the risk of open redirects while still leveraging Firestore for user-specific routing preferences.