Server Side Template Injection in Django with Firestore

Server Side Template Injection (SSTI) occurs when an attacker can inject template code that is executed on the server. In Django, this is uncommon because Django’s own template language is not typically used to render dynamic queries to Firestore. However, if a Django application uses a third-party template engine (such as Jinja2) to render configuration, documentation, or user-facing reports that include Firestore data, and user-controlled input is interpolated into those templates, SSTI becomes possible.

Firestore does not execute templates, but the danger arises when a compromised template uses Firestore client code to read or write data. For example, if a Django view passes user input into a Jinja2 template that then invokes firestore_client.collection(...), an attacker may be able to traverse object attributes, call methods, or access environment variables. This can lead to sensitive data exposure via Firestore reads, or potentially trigger unintended writes if the template is crafted to invoke write operations.

Consider a scenario where a Django app uses Jinja2 to generate admin reports by passing Firestore query results through a template. If an attacker can control a field that ends up in the template context, they may use SSTI to explore the object graph, access __class__, or invoke methods. Because Firestore SDK objects expose traversal paths and methods, an attacker may probe for configurations or credentials stored in the app environment. Even if Firestore itself does not evaluate expressions, the template can act as a conduit to escalate an information disclosure issue into a more impactful data exposure event.

Another angle is the use of dynamic collection or document names derived from user input that are rendered via a template engine. If a template embeds these names into rendered output that is later inspected or used by an operator, injection can aid in obfuscation or help an attacker probe for other weaknesses. The key risk is not Firestore executing code, but the template executing logic that interacts with Firestore in unexpected ways, exposing data or behavior that should remain restricted.

Because middleBrick tests unauthenticated attack surfaces and performs OpenAPI/Swagger spec analysis with full $ref resolution, it can highlight endpoints where user input flows into template rendering paths that eventually invoke Firestore operations. The scanner does not fix the issue, but it provides prioritized findings with severity and remediation guidance to help you address the injection path before sensitive data is exposed.

Remediation focuses on preventing user-controlled data from reaching template logic and ensuring Firestore interactions are explicit and safe. Avoid passing raw user input into any template context that could be rendered by a non-Django template engine. If you must use a third-party template engine, treat all input as untrusted and strictly validate or sanitize it before inclusion.

Use Django’s built-in template system for rendering, or, if using Jinja2, enforce a strict sandbox with no access to attributes or methods beyond explicitly allowed values. Never allow template evaluation of Firestore objects or SDK methods. Instead, extract the data you need in the view using the Firestore SDK and pass only primitive values (strings, numbers, booleans) to the template.

Below are concrete examples of unsafe and safe patterns when integrating Firestore with Django templates.

Unsafe pattern to avoid

import firebase_admin
from firebase_admin import firestore
from jinja2 import Template

# UNSAFE: user_input used directly in template logic
template = Template("Collection: {{ collection_name }}; Document fields: {{ doc_data }}")
user_input = request.GET.get('collection', 'users')
# Risk: attacker can manipulate collection_name to probe attributes
firestore_client = firestore.client()
coll = firestore_client.collection(user_input)
docs = coll.stream()
doc_data = [doc.to_dict() for doc in docs]
context = {
    'collection_name': user_input,
    'doc_data': doc_data  # Firestore objects or dicts passed into template
}
output = template.render(context)

In the unsafe example, user_input influences the collection name and is placed into the template context. If the template engine is Jinja2 and the context includes complex objects, an attacker may leverage SSTI to traverse or invoke methods.

Safe pattern with Firestore in Django

import firebase_admin
from firebase_admin import firestore
from django.shortcuts import render

# SAFE: explicit data extraction, no user input in template logic
def report_view(request):
    user_input = request.GET.get('collection', 'users')
    # Validate against an allowlist
    allowed_collections = {'users', 'orders', 'products'}
    if user_input not in allowed_collections:
        return render(request, 'error.html', {'message': 'Invalid collection'})
    
    firestore_client = firestore.client()
    coll = firestore_client.collection(user_input)
    docs = coll.stream()
    # Extract only primitive data
    doc_list = []
    for doc in docs:
        data = doc.to_dict()
        # Keep only safe, serializable fields
        safe_data = {k: v for k, v in data.items() if isinstance(v, (str, int, float, bool, list, dict))}
        doc_list.append(safe_data)
    
    # Pass only safe primitives to Django template
    return render(request, 'report.html', {
        'collection_name': user_input,
        'documents': doc_list
    })

In the safe pattern, collection names are validated against an allowlist, Firestore data is fully extracted and simplified to primitive types, and only these safe values reach the template. This removes the attacker’s ability to influence template behavior or probe Firestore object internals. middleBrick’s scans can help identify endpoints where user input reaches rendering contexts, giving you actionable findings with severity and remediation guidance to tighten this flow.

Additionally, for continuous protection, use the middleBrick CLI to scan from terminal with middlebrick scan <url>, add API security checks to your CI/CD pipeline with the GitHub Action, or integrate scans directly from your AI coding assistant via the MCP Server. The Pro plan supports continuous monitoring so that changes to template or Firestore usage are automatically re-evaluated for security regressions.