Django Penetrationstest: ORM-Sicherheit, SECRET_KEY-Management und Admin-Interface-Haertung

Django ist eines der aeltesten und ausgereiftesten Python-Web-Frameworks und bekannt fuer seine 'batteries included'-Philosophie und starke Sicherheitsgrundlage. Doch auch Django-Anwendungen enthalten haeufig kritische Schwachstellen: Raw-Query-Verwendungen im ORM umgehen den eingebauten Schutz, der SECRET_KEY ist in vielen Deployments kompromittiert, und das Django-Admin-Interface ist eines der haeufigsten Angriffsziele. CVE-2024-45230 (CVSS 7.5) demonstrierte DoS durch den strip_tags-Template-Filter; CVE-2024-39614 und CVE-2023-43665 belegten weitere Template-basierte Risiken.

Django Pentest starten

Geschrieben von Malte Wagenbach

Gründer von Matproof Security. Spezialisiert auf KI-gestützte Penetrationstests und EU-Compliance (DORA, NIS2, BSI Grundschutz, ISO 27001).

Zuletzt überprüft: 17. Mai 2026

Warum Django-Anwendungen spezialisierte Sicherheitspruefungen benoetigen

Djangos Sicherheitsreputation fuehrt manchmal dazu, dass Entwickler sich zu stark auf das Framework verlassen und eigene Implementierungsfehler uebersehen. Das ORM schuetzt zwar vor naiven SQL-Injections, aber 'raw()' und 'extra()'-Abfragen mit nicht-parametrisierten Eingaben umgehen diesen Schutz vollstaendig. Der SECRET_KEY ist der Kern von Djangos Sicherheitsmodell: Er signiert Cookies, Sessions und CSRF-Tokens. Ein bekannter oder schwacher SECRET_KEY ermoeglicht Session-Faelschung und CSRF-Bypass. Das Django-Admin-Interface, standardmaessig unter /admin/ erreichbar, ist ein beliebtes Angriffsziel fuer Credential-Stuffing und Brute-Force. Django REST Framework (DRF), die haeufigste API-Erweiterung, fuegt eigene Sicherheitskomplexitaeten hinzu.

CVE-2024-45230 (CVSS 7.5, DoS via strip_tags): Djangos Template-Filter 'strip_tags' konnte durch praeparierte Strings mit tief verschachtelten HTML-Tags einen exponentiellen Rechenaufwand verursachen, der zu Denial-of-Service fuehrte. Betrifft Django vor 4.2.16 und 5.0.x vor 5.0.9. Template-Filter werden haeufig auf Benutzerinput angewendet, was diesen Angriff fuer oeffentliche Formulare relevant macht.
CVE-2024-39614 (Denial-of-Service via URL-Aufloesung): Djangos URL-Resolver enthielt eine Schwachstelle, die durch spezifische URL-Muster einen ReDoS (Regular Expression Denial-of-Service) ausloesen konnte. Betrifft Django-Versionen vor 4.2.14 und 5.0.x vor 5.0.7.
CVE-2023-43665 (DoS via truncatechars_html): Djangos 'truncatechars_html'-Template-Filter enthielt eine DoS-Schwachstelle durch unkontrollierte Ressourcennutzung bei bestimmten HTML-Eingaben. Betrifft Django vor 3.2.23, 4.1.x vor 4.1.13 und 4.2.x vor 4.2.7.
SECRET_KEY-Kompromittierung als kritisches Risiko: Der Django-SECRET_KEY ist in tausenden GitHub-Repositories in .env-Dateien und settings.py-Dateien oeffentlich. Mit einem bekannten SECRET_KEY kann ein Angreifer gueltige Session-Cookies faelschem, CSRF-Tokens generieren und Django's Signing-Framework missbrauchen. Gitleaks und TruffleHog finden diese Leaks automatisch.
Django-Admin-Interface ohne ausreichende Haertung: /admin/ ist standardmaessig oeffentlich erreichbar und eines der meistangegriffenen Django-Endpunkte. Ohne Rate-Limiting, IP-Einschraenkung oder Zwei-Faktor-Authentifizierung ist es anfaellig fuer Brute-Force und Credential-Stuffing mit geleakten Zugangsdaten.
Django REST Framework Konfigurationsfehler: DRF verwendet standardmaessig SessionAuthentication und BasicAuthentication. Falsch konfigurierte Permission-Classes ('IsAuthenticated' vs. 'AllowAny'), DEFAULT_PERMISSION_CLASSES auf Projektebene versus View-Ebene und unkontrollierte Serializer koennen zu Autorisierungsluecken fuehren.
DEBUG=True in Produktionsumgebungen: Django im Debug-Modus liefert detaillierte Traceback-Seiten mit vollstaendigem Quellcode, lokalen Variablen, Datenbankverbindungen und Umgebungsvariablen. Dieser Fehler ist in Cloud-Deployments und CI/CD-Pipelines erschreckend haeufig.

Was beim Django Penetrationstest geprueft wird

ORM-Sicherheitsanalyse (Raw Queries, extra(), RawSQL): Vollstaendige Code-basierte Suche nach unsicheren ORM-Verwendungen; Test ob Benutzerinput in 'raw()', 'extra()', 'RawSQL()' oder 'execute()' ungeparametrisiert eingefuegt wird; SQL-Injection-Verifikation.
SECRET_KEY-Sicherheit und Konfigurationsaudit: Pruefung ob der SECRET_KEY mindestens 50 Zeichen aus einem zeichenreichen Zeichensatz besteht; Leakage-Pruefung in oeffentlichen Repositories, Logs, Fehlermeldungen; Empfehlung zur SECRET_KEY-Rotation via DJANGO_SECRET_KEY_FALLBACKS.
Django-Admin-Interface-Haertung: Test auf oeffentliche Erreichbarkeit; Brute-Force-Schutz und Rate-Limiting; Zwei-Faktor-Authentifizierung (django-otp oder Authy); Admin-Pfad-Obfuskation; Pruefung der ALLOWED_HOSTS-Konfiguration.
Template-Filter-DoS-Resistance: Test ob Benutzerinput durch strip_tags, truncatechars_html oder aehnliche Filter verarbeitet wird; Update-Pruefung auf aktuelle Django-Version ohne bekannte Template-CVEs; Input-Laengenbegrenzung.
Django REST Framework Autorisierungspruefung: Analyse der DEFAULT_PERMISSION_CLASSES; Test ob alle API-Views explizite Permission-Klassen definieren; BOLA/IDOR-Tests fuer alle ressourcenspezifischen Endpunkte; Serializer-Feldexposition.
CSRF-Schutz und Session-Sicherheit: Pruefung der CSRF-Middleware-Konfiguration; @csrf_exempt-Verwendungen; Session-Cookie-Flags (SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY, SESSION_COOKIE_SAMESITE); Session-Fixation-Angriffe.
Datei-Upload-Sicherheit: Pruefung ob hochgeladene Dateien auf erlaubte Typen validiert werden; Path-Traversal bei Dateinamen; Webshell-Upload via Bild-Upload-Endpunkte; MEDIA_ROOT-Konfiguration.
ALLOWED_HOSTS und HTTP-Host-Header-Injection: Test ob ALLOWED_HOSTS korrekt konfiguriert ist und keine Wildcards in Produktionsumgebungen enthaelt; Host-Header-Injection fuer Password-Reset-Emails.
Celery-und-Redis-Sicherheit: Falls Celery fuer asynchrone Tasks genutzt wird: Redis-Authentifizierung und Netzwerksegmentierung; Task-Deserialisierungs-Risiken; Pickle-Serialisierung als bekanntes RCE-Risiko.
Django-Abhangigkeitsaudit: Scan von requirements.txt gegen NVD und PyPA Advisory Database; Identifikation veralteter Django-Versionen und kritischer Plugin-CVEs (Django-CMS, Wagtail, Django-Admin-Honeypot).

Beispiel-Befund

Kritisch

SQL-Injection via unsichere ORM-Raw-Query in Suchfunktion

Die Produktsuchfunktion (GET /api/v1/products/search?q=) verwendet eine Raw-Query: 'Product.objects.raw(f"SELECT * FROM products WHERE name LIKE \'%{query}%\'" )'. Der Suchparameter 'q' wird ohne Parametrisierung direkt in den SQL-String eingefuegt. Im Test war UNION-basierte SQL-Injection moeglich: 'q=a' UNION SELECT username,password,null,null FROM auth_user-- ' lieferte alle Django-Benutzernamen und gehashten Passwoerter aus der Datenbank. OWASP A03:2021 Injection.

Behebung: Parametrisierung der Raw-Query: Product.objects.raw('SELECT * FROM products WHERE name LIKE %s', [f'%{query}%']). Alternativ Django-ORM verwenden: Product.objects.filter(name__icontains=query). Input-Laengenbegrenzung fuer den Suchparameter (max. 100 Zeichen). Datenbankbenutzer nur mit SELECT-Berechtigung fuer die Produktdatenbank.

Referenz: CVE-2024-45230 (Django strip_tags DoS) · CVE-2024-39614 (Django URL ReDoS) · OWASP A03:2021 Injection · CWE-89 SQL Injection · NVD Django Advisory

Django Pentest: Optionen im Vergleich

—	Kostenloser Scan	Matproof Sentinel	Klassische Beratung
Automatisierte Scan-Engine	✓ (3-min Vorschau)	✓ Vollständiger Scan	✗ Nur manuell
OWASP Top 10 Abdeckung	Partiell	✓ Vollständig	✓ Vollständig
Proof-of-Exploit-Evidenz	✗	✓ Pro Befund	✓ Pro Befund
Regulatorisches Mapping (DORA/NIS2/ISO 27001)	✗	✓ Automatisiert	✓ Manuell
Audit-tauglicher PDF-Bericht	✗	✓ Sofort	✓ 2–4 Wochen Lieferzeit
Kontinuierliche / wiederkehrende Scans	✗	✓ Pro Deploy	✗ Jährliches Engagement
Zeit bis zum ersten Ergebnis	~3 Min.	~30 Min. Vollscan	2–4 Wochen
Preis	€0	Ab €149	€8.000–€25.000
Quellcode-Review (SAST)	✗	✓ Im Growth-Plan	✓ Im Scope
API-Testing (REST/GraphQL)	✗	✓ Automatisiert	✓ Manuell

Django Pentest Pakete

Einzel-Scan

€149 einmalig

1 vollständiger Pentest-Scan
KI-priorisierte Befunde mit CVSS 3.1
Proof-of-Exploit für jedes Finding
PDF-Bericht (audit-tauglich)
Regulatorisches Mapping (DORA, NIS2, BSI)

Einzel-Scan kaufen →

Haeufige Fragen zum Django Penetrationstest

Ist Djangos ORM sicher gegen SQL-Injection oder gibt es Ausnahmen?

Djangos ORM-Standardmethoden (filter(), get(), exclude()) verwenden parametrisierte Abfragen und sind gegen SQL-Injection sicher. Die Ausnahmen sind: (1) 'raw()' und 'RawSQL()' mit nicht-parametrisierten Strings; (2) 'extra()' (veraltet, aber noch verwendet) mit where- oder tables-Parametern; (3) 'connection.cursor().execute()' mit direkt eingefuegten Variablen; (4) Suche via '__icontains' oder '__regex' mit potenziell langen Strings (ReDoS-Risiko). Beim Pentest suchen wir systematisch nach allen dieser Muster.

Wie sollte der Django SECRET_KEY in Produktionsumgebungen verwaltet werden?

Best Practices: (1) SECRET_KEY nicht in settings.py hartkodieren, sondern aus Umgebungsvariable lesen: SECRET_KEY = os.environ['DJANGO_SECRET_KEY']; (2) Min. 50 Zeichen aus einem zeichenreichen Zeichensatz (Gross-/Kleinbuchstaben, Ziffern, Sonderzeichen); (3) Nie in Git-Repositories committen -- .env in .gitignore aufnehmen; (4) Secrets-Manager verwenden (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault); (5) SECRET_KEY-Rotation via DJANGO_SECRET_KEY_FALLBACKS bei Verdacht auf Kompromittierung.

Wie haerte ich das Django-Admin-Interface ab?

Empfohlene Massnahmen fuer Django-Admin: (1) Admin-URL umbenennen (nicht /admin/, sondern ein schwer ratbarer Pfad); (2) ALLOWED_HOSTS korrekt konfigurieren; (3) Zwei-Faktor-Authentifizierung (django-otp, django-mfa2); (4) Rate-Limiting fuer Login-Versuche (django-ratelimit oder django-axes); (5) IP-Whitelist fuer Admin-Zugang wenn moeglich; (6) Getrennte Admin-Domain oder VPN-Anforderung fuer Admin-Zugriff; (7) Admin-Audit-Log (django-simple-history).

Welche Django REST Framework Konfigurationsfehler sind am haeufigsten?

Die haeufigsten DRF-Sicherheitsfehler: (1) DEFAULT_PERMISSION_CLASSES = [AllowAny] fuer die gesamte API, was alle Endpunkte oeffentlich macht; (2) Serializer, die alle Modellfelder exponieren (Meta: fields = '__all__') statt einer expliziten Feldliste; (3) fehlende object-level Autorisierung in get_queryset() -- alle Objekte aller User werden zurueckgegeben; (4) TokenAuthentication ohne Token-Expiration und -Rotation; (5) Pagination deaktiviert, was Datenenumeration erleichtert.

Was sind die Sicherheitsimplikationen von Django-DEBUG=True in Produktion?

DEBUG=True in Produktion ist eine kritische Fehlkonfiguration mit mehreren Konsequenzen: (1) Bei jedem Fehler werden vollstaendige Stack-Traces mit lokalem Quellcode und Variablen angezeigt; (2) Sensible Einstellungen aus settings.py werden in Fehlermeldungen ausgegeben (inkl. Datenbankpasswoerter, API-Schluessel); (3) ALLOWED_HOSTS wird nicht erzwungen; (4) Performance-Verschlechterung durch deaktiviertes Caching. Django zeigt bei DEBUG=False und korrekter ALLOWED_HOSTS-Konfiguration nur generische 500-Seiten.

Wie erkenne ich Celery-Sicherheitsluecken in Django-Anwendungen?

Celery-spezifische Risiken: (1) Pickle-Serialisierung (task_serializer = 'pickle') ist gefaehrlich und erlaubt Deserialisierungs-RCE bei kompromittiertem Message-Broker -- immer 'json' verwenden; (2) Redis als Broker ohne Authentifizierung und Netzwerksegmentierung -- von internen und externen Netzwerken erreichbar; (3) Celery-Ergebnisse enthalten sensible Daten und werden im Backend ohne Verschluesselung gespeichert; (4) CELERY_ALWAYS_EAGER in Tests kann Sicherheitspruefungen in Tasks deaktivieren.

Welche Django-Versions-CVEs sind aktuell am kritischsten?

Aktuelle kritische CVEs: CVE-2024-45230 (strip_tags DoS, Django < 4.2.16); CVE-2024-39614 (URL-Resolver ReDoS, Django < 4.2.14); CVE-2023-43665 (truncatechars_html DoS, Django < 4.2.7). Empfehlung: Immer die aktuelle Minor-Version des genutzten Django-Zweigs verwenden (z.B. 4.2.x LTS oder 5.0.x). Django veroeffentlicht Security-Releases typischerweise innerhalb von Tagen nach Entdeckung einer Schwachstelle.

Wie oft sollte eine Django-Anwendung einem Penetrationstest unterzogen werden?

Empfehlung: Vollstaendiger Pentest bei Django-Major-Version-Upgrade, nach substantiellen Feature-Erweiterungen und mindestens einmal jaehrlich. Kontinuierliches Monitoring mit Matproof Sentinel fuer sofortige CVE-Alerts. Bei DSGVO-relevanten Anwendungen oder Anwendungen unter BSI-Grundschutz sind haeufigere Tests (halbjaaehrlich) empfehlenswert.

Vertiefen — verwandte Artikel aus unserem Blog

Django Penetrationstest jetzt starten

Identifizieren Sie ORM-Injection-Risiken, SECRET_KEY-Kompromittierungen und Django-Admin-Schwachstellen in Ihrer Anwendung. Audit-bereiter Bericht auf Deutsch, keine Installation erforderlich.