Ssrf Server Side in Django with Mongodb

Server-side request forgery (SSRF) in a Django application that uses MongoDB can arise when user-controlled data is used to construct network calls or external resource identifiers and those values reach MongoDB operations or related infrastructure. In this stack, an attacker may supply a malicious URL or host that is not directly exploited at the HTTP layer, but influences how the backend interacts with MongoDB or auxiliary services. For example, if the application resolves a hostname from user input and then uses that host in a MongoDB connection string or passes it to an aggregation that performs $lookup or $graphLookup against external endpoints, the SSRF chain can extend into database-related operations. This is especially relevant when Django code dynamically builds MongoDB URIs, changes replica set configurations, or uses user input to form $lookup pipelines that reference external hosts.

Consider a scenario where a Django view accepts a hostname or IP from a request parameter and uses it to build a MongoDB connection or to validate whether a remote host is reachable before performing a lookup. If input validation is weak and the value is forwarded to pymongo operations such as MongoClient or $lookup stages, an attacker can direct internal traffic to sensitive internal services that are not exposed publicly. Because MongoDB exposes features like $lookup and $graphLookup, an attacker might coerce the backend to make outbound connections to internal resources, effectively turning SSRF into a pivot for data exfiltration or internal network reconnaissance.

In a Django + MongoDB architecture, SSRF can also manifest through log or monitoring integrations that forward data externally, or through features that fetch remote schemas or metadata. For instance, if an endpoint dynamically reflects or imports JSON schemas from user-provided URLs into MongoDB document structures or uses those URLs in change streams, the SSRF surface expands. Because Django often orchestrates multiple layers — web, database, and background tasks — the attack path may traverse HTTP handlers, middleware, and database drivers before reaching MongoDB.

To mitigate SSRF in Django with MongoDB, treat all user-controlled input as untrusted and avoid using it to construct MongoDB connections, URIs, or pipeline parameters that trigger outbound network activity. Validate and strictly limit any hostnames, IPs, or URLs before they interact with pymongo. Use allowlists for known safe values and reject input that references private IP ranges or internal hostnames.

Safe MongoDB connection setup

Instead of building a MongoDB URI from user input, configure the connection with static settings and use whitelisted identifiers for database operations. For example, define a fixed connection in Django settings and reference it safely in your code.

import pymongo
from django.conf import settings

# settings.py
MONGO_URI = "mongodb://user:[email protected]:27017/mydb?authSource=admin"

# views.py
client = pymongo.MongoClient(settings.MONGO_URI)
db = client["mydb"]

Validated $lookup usage

When using $lookup, avoid injecting untrusted hostnames or databases into the pipeline. Use hardcoded or configuration-driven collection and database names, and validate foreign field constraints rigorously.

from django.http import JsonResponse
from pymongo import MongoClient

def safe_lookup_view(request):
    allowed_collection = "products"
    user_value = request.GET.get("category", "")
    if user_value not in ["electronics", "books", "clothing"]:
        return JsonResponse({"error": "invalid category"}, status=400)

    client = MongoClient("mongodb://internal:27017/")
    db = client["shopdb"]
    result = db["items"].aggregate([
        {"$match": {"category": user_value}},
        {
            "$lookup": {
                "from": allowed_collection,
                "localField": "sku",
                "foreignField": "id",
                "as": "details"
            }
        }
    ])
    return JsonResponse(list(result), safe=False)

Reject dangerous input patterns

Implement checks that block IP addresses, internal hostnames, and suspicious URI schemes before they reach MongoDB operations. Combine Django form validation with pymongo usage to ensure no SSRF pivot is possible.

import re
from django import forms

INTERNAL_HOST_RE = re.compile(r"(^127\.0\.0\.1)|(^10\.)|(^192\.168\.)|(^172\.(1[6-9]|2[0-9]|3[01])\.)")

def is_internal_host(host: str) -> bool:
    return bool(INTERNAL_HOST_RE.match(host))

class ExternalLookupForm(forms.Form):
    external_host = forms.CharField(max_length=255)

    def clean_external_host(self):
        host = self.cleaned_data["external_host"]
        if is_internal_host(host):
            raise forms.ValidationError("Internal hosts are not allowed")
        if not host.endswith(".trusted.example.com"):
            raise forms.ValidationError("Host not in allowed domain")
        return host

Network-level hardening

Ensure MongoDB is bound only to trusted interfaces and that the Django application connects using accounts with minimal privileges. Even when input is validated, network segmentation prevents SSRF from reaching sensitive internal services. Combine these Django-side practices with MongoDB configuration to reduce exposure.