Path Traversal in Django with Mutual Tls

Path Traversal occurs when an application allows user-supplied input to reach the file system in a way that escapes the intended directory boundaries, commonly via sequences like ../. In Django, developers often rely on FileResponse or serve to deliver files, and may incorrectly trust validated paths or user-controlled identifiers. When Mutual Transport Layer Security (Mutual TLS) is in use, the server authenticates the client via client certificates, which can create a false sense of security. Operators may assume that because the channel is authenticated and encrypted, file access is similarly constrained. However, Mutual TLS only authenticates the peer; it does not enforce application-level authorization or path sanitization. An authenticated client can still send crafted parameters—such as a filename or path parameter—that traverse directories, potentially reaching sensitive locations like /etc/passwd or application configuration files. This is especially risky in environments where Django is fronted by a reverse proxy that terminates TLS and forwards requests over plain HTTP internally, or when client certificates are used to reduce additional authentication steps, leading developers to relax input validation. The combination therefore exposes a gap: strong transport-layer identity does not prevent logical path manipulation bugs.

Consider a view that serves files from a user-specific directory using a certificate-derived identifier without canonicalization:

import os
from django.http import FileResponse
from django.conf import settings

def user_file(request, filename):
    user_id = request.META.get('SSL_CLIENT_S_DN_CN')  # from client cert
    base = os.path.join(settings.MEDIA_ROOT, user_id)
    path = os.path.join(base, filename)  # vulnerable if filename contains '../'
    if os.path.commonpath([path, base]) != base:
        # Incorrect assumption: client cert validated, so path is safe
        return FileResponse(open(path, 'rb'))
    return HttpResponseForbidden()

An attacker who controls filename can supply ../../../etc/passwd. Even with Mutual TLS ensuring the request originates from a trusted client, the application logic does not prevent access outside base. Moreover, if the view uses Django’s sendfile-style patterns or relies on X-Sendfile headers, the server backend may interpret paths without proper sandboxing. The presence of Mutual TLS can therefore indirectly encourage insecure coding practices, increasing the likelihood of Path Traversal.

Remediation centers on strict input validation, path canonicalization, and avoiding reliance on transport-layer identity for authorization. Always resolve paths to their absolute canonical form and ensure they remain within the intended directory tree. Do not use client certificate fields as the sole basis for directory traversal prevention.

Secure example using explicit base resolution and os.path.realpath:

import os
from django.http import FileResponse, HttpResponseForbidden
from django.conf import settings

def user_file(request, filename):
    user_id = request.META.get('SSL_CLIENT_S_DN_CN')
    if not user_id:
        return HttpResponseForbidden()
    base = os.path.realpath(os.path.join(settings.MEDIA_ROOT, user_id))
    requested = os.path.realpath(os.path.join(base, filename))
    # Ensure the resolved path is under base
    if os.path.commonpath([requested, base]) != base:
        return HttpResponseForbidden()
    if not os.path.isfile(requested):
        return HttpResponseForbidden()
    return FileResponse(open(requested, 'rb'))

When using Django’s FileResponse, prefer passing a file descriptor opened from a validated path rather than a raw string, and ensure the file is opened with appropriate permissions. For dynamic file delivery via views that use storage backends, apply the same canonicalization logic.

If you rely on reverse proxy configurations for Mutual TLS, ensure the application does not trust headers like X-Forwarded-For for security decisions without proper proxy hardening. Use Django’s SECURE_PROXY_SSL_HEADER only when you control the proxy chain and understand its implications:

# settings.py
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

In environments where client certificates map to users, combine certificate validation with application-level permissions (e.g., a database or directory ACL) and avoid concatenating user input directly into filesystem paths. Regularly audit file-serving endpoints with black-box scans to detect regressions, and consider integrating middleBrick’s scans into your CI/CD pipeline using the GitHub Action to fail builds if risk scores degrade.