Clickjacking in Django with Mutual Tls

Clickjacking is a client-side attack where an attacker tricks a user into interacting with invisible or disguised UI elements inside an embedded frame. In Django, this typically manifests via missing or weak Content Security Policy (CSP) frame-ancestors rules and the absence of X-Frame-Options, enabling pages to be embedded on malicious sites. Mutual Transport Layer Security (mTLS) adds strong client authentication using client certificates but does not protect against clickjacking. mTLS ensures the identity of the client and server, yet it does not restrict how a validated response is rendered or framed by the browser. Consequently, an API or web endpoint protected with mTLS can still be embedded in an attacker’s page if CSP and X-Frame-Options are not properly configured, leading to clickjacking despite strong mutual authentication.

When combining Django with mTLS, developers may assume that strong transport-layer authentication is sufficient. However, security checks such as those performed by middleBrick identify missing frame-protection headers even when mTLS is in place. middleBrick scans unauthenticated attack surfaces and flags issues like absent X-Frame-Options or overly permissive CSP frame-ancestors, regardless of whether client certificates are required. The tool also runs OWASP API Top 10-aligned checks across 12 parallel tests, including Input Validation and BOLA/IDOR, which can highlight endpoints that expose data in embeddable contexts. Because middleBrick references findings to real frameworks such as OWASP and maps them to compliance regimes like PCI-DSS and SOC2, it helps teams understand that mTLS does not mitigate UI redressing threats.

An mTLS-enabled Django service may still expose sensitive actions in iframes, especially when APIs return JSON that is consumed by a frontend rendered inside a frame. For example, a bank’s internal service using client certificates might deliver a payment confirmation endpoint that, without proper CSP, can be loaded on a phishing site and trick users into confirming unintended transactions. middleBrick’s LLM/AI Security checks, such as system prompt leakage detection and active prompt injection testing, are unique in uncovering risks around exposed functionality, but for traditional web UIs, the primary defense remains HTTP headers. The scanner’s per-category breakdown clarifies severity and provides remediation guidance, emphasizing that headers must explicitly prevent framing rather than relying on transport assurance alone.

Securing Django against clickjacking while using mTLS involves two layers: transport assurance and response header hardening. mTLS is configured at the web server or reverse proxy (e.g., Nginx, Envoy) in front of Django, while clickjacking defenses are implemented in Django middleware and settings. Below are concrete configurations and code examples.

Django Settings for Clickjacking Protection

Ensure CSP includes a strict frame-ancestors directive and set X-Frame-Options for broader compatibility. In settings.py:

import os

# settings.py

# Content Security Policy to prevent framing
CSP_DEFAULT_SRC = ("'self'",)
CSP_FRAME_ANCESTORS = ("'self'",)  # Prevents embedding on external sites

# Legacy defense for browsers that do not support CSP
X_FRAME_OPTIONS = 'DENY'
X_FRAME_OPTIONS_EXCLUDE_PATHS = []  # leave empty to apply globally

# Security HSTS (optional, transport hardening)
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_SSL_REDIRECT = True

mTLS Configuration Example (Nginx Ingress)

Mutual TLS is typically enforced at the ingress or load balancer. Here is an Nginx example that requires client certificates and passes the verified client identity to Django via a header (e.g., SSL_CLIENT_CERT or a mapped subset). This keeps mTLS enforcement outside Django while allowing Django to make decisions based on verified attributes if needed.

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc/ssl/private/server.key;

    # Enable mutual TLS
    ssl_verify_client on;
    ssl_client_certificate /etc/ssl/certs/ca.crt;

    # Optionally verify depth and constraints
    ssl_verify_depth 2;

    # Pass client certificate info to Django (useful for auditing)
    proxy_set_header X-SSL-Client-Verify $ssl_client_verify;
    proxy_set_header X-SSL-Client-DN $ssl_client_s_dn;

    location / {
        proxy_pass http://django_app;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Django Middleware to Validate Header Consistency

Optionally, add lightweight middleware to assert that mTLS-derived headers are present for sensitive views, while still enforcing CSP and X-Frame-Options for all responses. This does not replace mTLS but provides defense-in-depth for audit trails.

# middleware.py

class MtlsAuditMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        # Example: log or restrict if missing expected client cert headers
        if not request.META.get('HTTP_X_SSL_CLIENT_VERIFY') == 'SUCCESS':
            # You may choose to reject or flag; here we only audit
            pass
        response = self.get_response(request)
        return response

Testing the Headers

Verify that both mTLS and frame protection are working. Use curl to check headers (client cert required for mTLS endpoints):

curl -v --cert client.crt --key client.key https://api.example.com/health
# Observe X-Frame-Options: DENY and CSP headers in the response