Server Side Template Injection in Django with Basic Auth

Server Side Template Injection (SSTI) in Django with HTTP Basic Authentication involves two distinct but related concerns: how Django templates can be abused when developer-controlled data reaches the rendering layer, and how exposing administrative or debug endpoints over Basic Auth can increase risk. SSTI occurs when an attacker can inject template code that is subsequently evaluated by the template engine, often via unsanitized user input used in template rendering, custom template tags, or dynamic inclusion of template snippets.

When Basic Auth is used without additional access controls, endpoints that render templates may become reachable to a broader set of credentials or to unauthenticated scanners during reconnaissance (middleBrick tests unauthenticated attack surfaces by default). If a view accepts user input—such as a username, search term, or configuration key—and passes it directly into a template that uses {% include %}, {% with %}, or custom template tags, an attacker may be able to control which template block is rendered or which variable context is evaluated. In Django, this can manifest through misuse of render, TemplateResponse, or third-party packages that extend the template language.

Django’s built-in template engine is not Turing-complete and has sandboxed execution, which limits the direct impact compared to some other languages; however, template injection can still lead to unauthorized information disclosure, such as reading file paths via {% debug %} in development, or indirect data exfiltration through included templates that reference request attributes. When Basic Auth guards an admin or debug view, misconfigured permissions or accidental exposure can allow an attacker to combine credential guessing or credential spraying with SSTI probes, especially if the same endpoint is also reachable internally by other services.

Using middleBrick’s unauthenticated scan, findings related to SSTI may surface as input validation issues or improper dynamic template inclusion, while LLM/AI Security checks can detect whether system prompts or sensitive context are inadvertently exposed through injected template variables. Because Django projects often rely on nested template inheritance and third-party template tags, verifying that user-controlled data is never used to select template names, paths, or block identifiers is essential. Security testing should therefore include both authenticated and unauthenticated scenarios to ensure that Basic Auth–protected views do not inadvertently expand the attack surface through template logic.

Remediation focuses on strict input validation, avoiding dynamic template selection, and ensuring that Basic Auth is used only where appropriate with additional access controls. Never use user input to construct template names, paths, or block identifiers. Instead, use a strict allowlist and pass only sanitized data to the context.

Safe view patterns with HTTP Basic Auth

• Do not render templates based on raw user input. If you must include user-derived values, treat them as data, not template instructions.
• Use Django’s built-in authentication and permissions rather than relying solely on Basic Auth for access control.

Example: Unsafe pattern to avoid

# Unsafe: using user input to select a template block or template name
from django.shortcuts import render
from django.contrib.auth.decorators import login_required
import base64

def unsafe_view(request):
    encoded = request.GET.get('section', '')
    # Decoding user input to pick a template block is unsafe
    try:
        section = base64.b64decode(encoded).decode('utf-8')
    except Exception:
        section = 'default'
    # This can lead to template injection if section maps to a user-controlled template
    return render(request, f'sections/{section}.html', {'data': section})

Example: Safe pattern with explicit allowlist

# Safe: using an allowlist and constant templates
from django.shortcuts import render
from django.contrib.auth.decorators import login_required

ALLOWED_SECTIONS = {'profile', 'settings', 'help'}

@login_required
def safe_view(request):
    section = request.GET.get('section', 'profile')
    if section not in ALLOWED_SECTIONS:
        # Reject unexpected values; do not attempt to guess templates
        return render(request, 'errors/invalid_section.html', status=400)
    # Use a constant template path; no user-controlled path components
    return render(request, 'app/profile_section.html', {'section': section})

Example: HTTP Basic Auth with additional permissions

# views.py
from django.http import HttpResponse
from django.views.decorators.http import require_http_methods
import base64
import logging

logger = logging.getLogger(__name__)

@require_http_methods(["GET"])
def basic_auth_view(request):
    auth_header = request.META.get('HTTP_AUTHORIZATION', '')
    if not auth_header.startswith('Basic '):
        return HttpResponse('Unauthorized', status=401, headers={'WWW-Authenticate': 'Basic realm="API"'})
    try:
        encoded = auth_header.split(' ')[1]
        decoded = base64.b64decode(encoded).decode('utf-8')
        username, password = decoded.split(':', 1)
    except Exception:
        return HttpResponse('Invalid auth header', status=400)
    # Perform constant-time check in real usage; this is illustrative
    if username == 'admin' and password == 'secret':
        # Even with valid credentials, validate and sanitize any downstream data
        return HttpResponse('Access granted')
    logger.warning('Failed basic auth attempt')
    return HttpResponse('Unauthorized', status=401)

Additional hardening steps

• Set DEBUG = False in production to prevent debug template information leakage.
• Use Django middleware to restrict HTTP methods and validate the Host header.
• Combine Basic Auth with IP allowlisting or session-based controls for sensitive endpoints.