Insufficient Logging in Django with Mutual Tls

Insufficient logging in a Django application using mutual TLS (mTLS) creates a security gap where failed authentication events, certificate validation outcomes, and suspicious request patterns are not recorded. Without these logs, an operator cannot reconstruct the sequence of TLS handshake failures, identify presented client certificates, or detect credential or certificate abuse. In an mTLS deployment, the server validates client certificates issued by a trusted CA; if logging does not capture the certificate subject, issuer, serial number, validation result, and the associated user or endpoint, attackers can probe the API with invalid or revoked certificates and remain undetected.

For example, consider a Django project that terminates mTLS at the reverse proxy and forwards requests with a validated client certificate via a header like SSL_CLIENT_CERT. If Django’s logging does not extract and record the certificate details, an attacker can repeatedly attempt stolen or forged certificates and the system will lack evidence needed for incident response. Additionally, logging only successful authentication while omitting TLS-specific checks means security teams miss critical signals required to detect patterns such as rapid certificate retries, unusual certificate-subject usage, or requests that bypass expected authorization logic (BOLA/IDOR). These gaps are especially risky when combined with other API security issues like excessive agency or unsafe consumption, because insufficient logs prevent detection of abuse paths that mTLS alone does not block.

middleBrick’s security checks include unauthenticated API scanning, which can surface whether an API endpoint lacks sufficient logging for mTLS-related events. By correlating OpenAPI specifications with runtime findings, the scanner highlights missing observability for critical security controls. This enables teams to remediate by ensuring logs capture certificate metadata, validation outcomes, and request context, making it substantially harder for attackers to operate silently.

To address insufficient logging in Django with mTLS, instrument certificate extraction and validation logging at the point where the server receives and verifies client certificates. Below are concrete, syntactically correct examples for two common deployment patterns: (1) mTLS terminated at a reverse proxy with the certificate forwarded via headers, and (2) mTLS handled directly in Django using WSGI middleware.

1) Reverse proxy termination (e.g., Nginx) with header passthrough

Configure your reverse proxy to export certificate fields as request headers, and ensure Django logs them on each request. Example Nginx snippet:

ssl_client_certificate /etc/ssl/certs/ca.pem;
ssl_verify_client on;
proxy_set_header SSL_CLIENT_CERT $ssl_client_cert;
proxy_set_header SSL_CLIENT_CERT_SUBJECT $ssl_client_cert_subject;
proxy_set_header SSL_CLIENT_CERT_ISSUER $ssl_client_cert_issuer;
proxy_set_header SSL_CLIENT_CERT_SERIAL $ssl_client_cert_serial;

In Django, add a request logging middleware to capture these headers and relevant outcome data:

import logging
from django.utils.deprecation import MiddlewareMixin

logger = logging.getLogger(__name__)

class MTLSDebugLoggingMiddleware(MiddlewareMixin):
    def process_request(self, request):
        client_cert = request.META.get('HTTP_SSL_CLIENT_CERT')
        cert_subject = request.META.get('HTTP_SSL_CLIENT_CERT_SUBJECT')
        cert_issuer = request.META.get('HTTP_SSL_CLIENT_CERT_ISSUER')
        cert_serial = request.META.get('HTTP_SSL_CLIENT_CERT_SERIAL')
        # Log basic receipt of certificate material
        logger.info(
            'mTLS header received',
            extra={
                'client_cert_present': bool(client_cert),
                'cert_subject': cert_subject,
                'cert_issuer': cert_issuer,
                'cert_serial': cert_serial,
                'path': request.path,
                'method': request.method,
            }
        )
        # Optionally parse PEM and log certificate metadata (thumbprint, SANs) here,
        # for example using cryptography.x509.load_pem_x509_certificate(client_cert.encode())
        return None

# In settings.py, ensure the middleware is placed after security middleware:
# MIDDLEWARE = [
#     ...,
#     'yourapp.middleware.MTLSDebugLoggingMiddleware',
# ]

This ensures each request records whether a client certificate was presented, who it was issued to, and by whom, enabling detection of repeated invalid certificates and correlating events with user accounts or API keys.

2) mTLS handled directly in Django (e.g., via WSGI wrapper)

When Django validates client certificates directly at the WSGI layer, log the validation result alongside the request. Example WSGI middleware:

import logging
import ssl

logger = logging.getLogger(__name__)

class MutualTLSLoggingMiddleware:
    def __init__(self, app):
        self.app = app

    def __call__(self, environ, start_response):
        cert = environ.get('SSL_CLIENT_CERT')
        verify_result = environ.get('SSL_CLIENT_VERIFY', 'UNSET')
        subject = environ.get('SSL_CLIENT_CERT_SUBJECT')
        issuer = environ.get('SSL_CLIENT_CERT_ISSUER')
        serial = environ.get('SSL_CLIENT_CERT_SERIAL')
        logger.info(
            'mTLS WSGI verification',
            extra={
                'cert_present': bool(cert),
                'verify_result': verify_result,
                'subject': subject,
                'issuer': issuer,
                'serial': serial,
                'path': environ.get('PATH_INFO'),
            }
        )
        return self.app(environ, start_response)

# In your ASGI/WSGI application setup (e.g., application.py):
# from yourapp.middleware import MutualTLSLoggingMiddleware
# application = MutualTLSLoggingMiddleware(application)

These patterns ensure that for every request, you record the certificate’s presence, validation outcome, and identity details. Combined with Django’s existing security logging, this makes it significantly harder for attackers to abuse weak observability when exploiting other API weaknesses.