Llm Data Leakage in Django with Basic Auth

When a Django API endpoint relies on HTTP Basic Authentication and exposes data or functionality that can be accessed without explicit user consent, it can become a channel for Large Language Model (LLM) data leakage. In this context, an unauthenticated or improperly scoped LLM integration—such as a service that forwards user queries to an LLM endpoint—might inadvertently surface protected information if the upstream API accepts requests that should be restricted to authenticated, authorized contexts.

Basic Auth in Django is commonly implemented via middleware or view decorators (e.g., django.contrib.auth.decorators.login_required is not enough for HTTP Basic Auth). If developers assume Basic Auth alone is sufficient to protect an endpoint used by an LLM-integrated service, they risk leaking sensitive data when the LLM tooling or a misconfigured client makes requests without proper credentials or with excessive scopes. For example, an endpoint like /api/v1/users/{user_id}/preferences that returns personal settings could be called by an LLM-integrated agent that does not enforce per-user authorization, leading to disclosure of one user’s data to another or to an external system.

The LLM/AI Security checks in middleBrick specifically probe for unauthenticated LLM endpoints and system prompt leakage, which can be exacerbated when Basic Auth is present but not rigorously enforced across all request paths. If an LLM service is reachable without authentication and mirrors or caches API responses, sensitive data such as PII, API keys, or business logic can appear in model outputs or logs. Attackers may use prompt injection techniques to coax the LLM into revealing training data or cached responses that should have been protected by Basic Auth but were exposed due to inconsistent enforcement.

Additionally, the combination of Basic Auth and LLM tooling can create risk if the API’s OpenAPI spec defines security schemes but runtime behavior does not match. middleBrick’s OpenAPI/Swagger analysis resolves $ref definitions and cross-references them with runtime findings, highlighting mismatches where an endpoint appears protected in the spec but is accessible without proper credentials during LLM-linked interactions. This is critical because LLM agents often make autonomous requests; if those requests bypass Basic Auth or ignore scope constraints, the data exposure risk increases.

Concrete attack patterns include an LLM agent making repeated calls to a Basic Auth-protected endpoint without embedding credentials, or a developer inadvertently allowing the LLM to log raw responses that contain credentials or PII. middleBrick’s Active Prompt Injection testing (five sequential probes) and Output Scanning for PII, API keys, and executable code help surface these issues by simulating how an LLM might misuse exposed endpoints. The scanner also flags Unauthenticated LLM Endpoints and Excessive Agency patterns, which are especially relevant when Basic Auth is misconfigured or inconsistently applied across the API surface.

To mitigate LLM data leakage in Django when using Basic Auth, enforce authentication consistently, scope access per user or role, and ensure LLM integrations respect the same protections. Below are concrete, secure implementations.

1. Enforce Basic Auth with Django middleware

Use HTTP Basic Auth at the middleware level so that all relevant views require valid credentials. This prevents accidental exposure when new endpoints are added or when LLM tools make autonomous requests.

from django.utils.deprecation import MiddlewareMixin
from django.http import HttpResponse
import base64

class BasicAuthMiddleware(MiddlewareMixin):
    def process_request(self, request):
        auth_header = request.META.get('HTTP_AUTHORIZATION')
        if auth_header and auth_header.startswith('Basic '):
            encoded = auth_header.split(' ')[1]
            decoded = base64.b64decode(encoded).decode('utf-8')
            username, password = decoded.split(':', 1)
            user = authenticate(request, username=username, password=password)
            if user is not None:
                request.user = user
            else:
                return self._unauthorized()
        else:
            return self._unauthorized()

    def _unauthorized(self):
        response = HttpResponse('Unauthorized', status=401)
        response['WWW-Authenticate'] = 'Basic realm="api"'
        return response

2. Protect specific views with decorator and request checks

For finer control, apply authentication at the view level and validate that the requesting user has permission to access the target resource (e.g., user-specific data).

from django.contrib.auth.decorators import login_required
from django.http import JsonResponse
from django.shortcuts import get_object_or_404

@login_required
def user_preferences(request, user_id):
    if request.user.id != user_id:
        return JsonResponse({'error': 'Forbidden'}, status=403)
    # Fetch and return preferences for the requesting user
    preferences = get_object_or_404(UserPreferences, user_id=user_id)
    return JsonResponse({'theme': preferences.theme, 'notifications': preferences.notifications})

3. Secure LLM integration points

If your Django API is consumed by an LLM agent or external service, ensure that every request includes valid Basic Auth credentials and that the endpoint validates both authentication and authorization. Avoid allowing the LLM to infer or guess endpoints that should be protected.

import requests
from requests.auth import HTTPBasicAuth

def call_protected_api(user_id, username, password):
    url = f'https://api.example.com/api/v1/users/{user_id}/preferences'
    response = requests.get(url, auth=HTTPBasicAuth(username, password))
    if response.status_code == 200:
        return response.json()
    else:
        raise Exception(f'API call failed: {response.status_code}')

4. Validate and limit data exposure in responses

Ensure that responses do not include sensitive fields unless necessary. Use serializers or explicit field selection to prevent accidental data leakage to LLM-integrated consumers.

from rest_framework import serializers

class UserPreferencesSerializer(serializers.Serializer):
    theme = serializers.CharField()
    notifications = serializers.BooleanField()
    # Do NOT include fields like 'ssn' or 'api_key'

5. Use middleware to strip or redact sensitive headers in LLM-bound requests

If your Django app forwards requests to an LLM service, strip or redact Authorization headers and PII before forwarding to avoid leaking credentials through the LLM pipeline.

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

    def __call__(self, request):
        # Remove sensitive headers when forwarding to LLM services
        llm_request_headers = dict(request.headers)
        llm_request_headers.pop('Authorization', None)
        llm_request_headers.pop('Cookie', None)
        # Proceed with request or forward sanitized headers as needed
        response = self.get_response(request)
        return response