Server Side Template Injection in Django with Cockroachdb

Server Side Template Injection (SSTI) occurs when an attacker can inject template code that is subsequently rendered by a server-side template engine. In Django, this typically arises when user-supplied data is passed into template rendering functions such as Template.render() or when dynamic template selection is based on unchecked input. While Django’s default template language is designed to be sandboxed, misuse of low-level APIs can enable object injection, code execution, or unintended data exposure.

When Django interacts with Cockroachdb — a PostgreSQL-compatible distributed SQL database — the risk is not in the database itself, but in how data retrieved from Cockroachdb is handled before being rendered in templates. If rows fetched from Cockroachdb contain user-controlled content (for example, a product_description or comment_text column) and that data is directly passed into a Django template for rendering, an attacker who can influence stored content may achieve SSTI if template rendering is later invoked with unsafe constructs.

A concrete scenario: an application stores marketing content in Cockroachdb using a JSONField or TextField, and later uses {% autoescape off %} or the safe filter to render that content. If the stored content includes template syntax such as {{ user.password }} or malicious tags, and the template engine processes it with Template instead of TemplateResponse, arbitrary template code can be executed in the context of the request. This can lead to information disclosure, local file inclusion, or even remote code execution depending on available context variables.

Additionally, dynamic template loading based on unvalidated identifiers from Cockroachdb — such as loading a template name stored in a row — can allow an attacker to cause the application to instantiate attacker-controlled template files. Because Cockroachdb often serves as a source of truth for application content, developers may mistakenly trust its data as safe, overlooking the need for input validation and output encoding before template rendering.

Remediation centers on strict separation of data and rendering, avoiding unsafe template APIs, and validating any data retrieved from Cockroachdb before use in templates. Below are concrete, safe patterns for working with Cockroachdb in Django.

Safe data retrieval and template usage

Always treat data from Cockroachdb as untrusted. Use Django’s built-in template auto-escaping and avoid autoescape off or the safe filter on dynamic content.

# models.py
from django.db import models

class Content(models.Model):
    body = models.TextField()  # potentially user-controlled
    created_at = models.DateTimeField(auto_now_add=True)

# views.py
from django.shortcuts import render
from .models import Content

def content_view(request, content_id):
    # Safe: fetch from Cockroachdb via Django ORM
    content_obj = Content.objects.get(id=content_id)
    # Safe: pass raw data to template; rely on auto-escaping
    return render(request, "content_detail.html", {"content": content_obj.body})

Avoid dynamic template loading based on database values

Do not use data from Cockroachdb to select template names or paths. If dynamic templates are necessary, map identifiers to a whitelist.

# views.py
ALLOWED_TEMPLATES = {"newsletter": "emails/newsletter.html", "receipt": "emails/receipt.html"}

def send_template_email(request, template_key):
    from django.core.mail import EmailMessage
    from django.template.loader import render_to_string

    if template_key not in ALLOWED_TEMPLATES:
        raise ValueError("Invalid template key")
    template_name = ALLOWED_TEMPLATES[template_key]
    # Safe: template name is controlled by code, not by database input
    html_content = render_to_string(template_name, {"data": "example"})
    EmailMessage("Subject", html_content, to=["[email protected]"]).send()

Use parameterization for Cockroachdb queries and strict validation

Always use parameterized queries via Django ORM or cursor parameters to avoid injection into SQL, and validate any identifiers used in template logic.

# Safe query patterns with Cockroachdb through Django ORM
from django.db import connection

# Using ORM (recommended)
rows = Content.objects.filter(category__in=["news", "updates"])

# Using parameterized raw SQL if needed
def search_content(keyword):
    from django.db import connection
    with connection.cursor() as cursor:
        cursor.execute("SELECT body FROM content_table WHERE body ILIKE %s", [f"%{keyword}%"])
        return cursor.fetchall()

Template-side best practices

• Keep autoescape enabled (default in Django templates).
• Use template filters like escape or linebreaks on dynamic fields.
• Avoid Template class for user-influenced content; prefer render or TemplateResponse.