TYPO3 Security Hardening Guide – Best Practices für Produktion
Praxisorientierter Leitfaden zur Absicherung von TYPO3-Instanzen: Server-Konfiguration, Application Context, Extension-Management und Incident Response. Mit Konfigurationsbeispielen und offiziellen Quellen.
Die Sicherheit einer TYPO3-Installation ist das Ergebnis einer geteilten Verantwortung aller Beteiligten – Systemadministrator:innen, Integrator:innen, Entwickler:innen und Redakteur:innen. Dieser Leitfaden basiert auf dem offiziellen TYPO3 Security Guide und fasst alle relevanten Sicherheitsmaßnahmen zusammen.
Inhaltsverzeichnis
Security Team
Verantwortlichkeiten, Schwachstellen melden
Bedrohungen
SQLi, XSS, CSRF, RCE, Path Traversal, Brute-Force
Schnell-Checkliste
Sortiert nach Priorität – kritische Maßnahmen zuerst.
Kritisch – Sofort umsetzen
.* in ProduktionFehlerausgabe deaktiviert – displayErrors = 0, devIPmask = ''Aktuelle LTS-Version – TYPO3 12 oder 13 LTS mit neuesten PatchesExtensions aktuell – Alle Erweiterungen aktuell, ungenutzte entferntHoch – Authentifizierung & Zugriff
loginRateLimit konfiguriert (v13+: nativ, v12: fail2ban)Minimale Rechte – Benutzer haben nur notwendige Berechtigungen (PoLP)Mittel – Infrastruktur
composer auditSensible Dateien blockiert – .sql, .yaml, composer.* nicht erreichbarSecurity Headers gesetzt – HSTS, X-Frame-Options, CSP konfiguriertWartung & Recovery
TYPO3 Security Team
Das TYPO3 Security Team ist verantwortlich für die Koordination und Kommunikation von Sicherheitslücken im gesamten TYPO3-Ökosystem.
Aufgaben
- Entgegennahme und Verifizierung von Sicherheitsmeldungen
- Koordination mit Core- und Extension-Entwickler:innen
- Veröffentlichung von Security Bulletins und Patches
- Pflege der Security Advisories Datenbank
Schwachstellen melden
- E-Mail: security@typo3.org (verschlüsselt möglich)
- Niemals öffentlich: Keine GitHub-Issues, keine Forge-Tickets
- Responsible Disclosure: Koordinierte Veröffentlichung nach Patch
- Anerkennung: Credits in Security Bulletins
Sicherheitslücken dürfen niemals öffentlich diskutiert werden, bevor ein Patch verfügbar ist. Dies gibt Angreifern einen Vorteil und gefährdet alle TYPO3-Installationen weltweit.
Versionen & Updates
Die Wahl der richtigen TYPO3-Version und eine konsequente Update-Strategie sind fundamentale Sicherheitsentscheidungen.
Support-Zyklen
| Version | Typ | Regulärer Support | ELTS verfügbar | PHP-Version |
|---|---|---|---|---|
| TYPO3 14 | Sprint → LTS (April 2026) | Bis ~April 2029 | Ja (danach) | PHP 8.2+ |
| TYPO3 13 | LTS | Bis Oktober 2027 | Ja (danach) | PHP 8.2+ |
| TYPO3 12 | LTS | Bis April 2026 | Ja (danach) | PHP 8.1+ |
| TYPO3 11 | LTS | Beendet | Ja (kostenpflichtig) | PHP 7.4–8.2 |
| Sprint Releases | Entwicklung | Kein Support | Nein | variiert |
TYPO3 v14.0 wurde am 25. November 2025 veröffentlicht. Die LTS-Version (v14.4) ist für April 2026 geplant. Bis dahin können sich Features und Einstellungen noch ändern. PHP 8.2+ ist erforderlich.
Nach Ende des regulären Supports können kritische Sicherheitsupdates über das kostenpflichtige ELTS-Programm bezogen werden. Dies ist für Legacy-Systeme relevant, die nicht zeitnah migriert werden können.
Update-Kategorien
Maintenance Releases
- Fehlerbehebungen und kleinere Verbesserungen
- Planbar im regulären Sprint-Rhythmus
- Beispiel: 12.4.10 → 12.4.11
Security Releases
- Beheben kritische Sicherheitslücken
- Sofortige Installation erforderlich (24h-Ziel)
- Dienstags veröffentlicht (koordiniert)
Da TYPO3 Open-Source ist, können Angreifer nach Veröffentlichung eines Patches die Code-Änderungen analysieren und Exploits entwickeln. Handeln Sie bei Security Releases innerhalb von 24 Stunden.
Bedrohungsarten
Um TYPO3-Systeme effektiv zu schützen, müssen die gängigsten Angriffsvektoren verstanden werden.
Allgemeine Richtlinien
Diese Grundprinzipien gelten für alle Rollen und bilden das Fundament jeder Sicherheitsstrategie.
Passwort-Hygiene
Anforderungen
- Mindestens 12 Zeichen (besser: 16+)
- Groß-/Kleinbuchstaben, Zahlen, Sonderzeichen
- Keine persönlichen Daten oder Wörterbuchwörter
- Passwort-Manager verwenden
Organisatorisch
- Für jeden Dienst ein einzigartiges Passwort
- Kein "Angemeldet bleiben" auf gemeinsam genutzten Geräten
- Passwörter niemals per E-Mail oder Chat teilen
- Regelmäßige Rotation nach Sicherheitsrichtlinie
Informiert bleiben
- Security Bulletins: typo3.org/help/security-advisories
- Newsletter: TYPO3 Security Announcements abonnieren
- RSS Feed: Automatische Benachrichtigung über neue Advisories
Client-Sicherheit
Alle Geräte, die auf das TYPO3-Backend zugreifen, müssen abgesichert sein:
- Betriebssystem und Browser aktuell halten
- Antivirus-Software und Firewall aktivieren
- Keine Installation von Software aus unbekannten Quellen
- VPN für Zugriff aus öffentlichen Netzwerken
Systemadministration
Systemadministrator:innen verantworten die Server-Infrastruktur und damit die Basis aller Sicherheitsmaßnahmen.
HTTPS-Verschlüsselung
Ohne HTTPS können Anmeldedaten, Session-Cookies und sensible Inhalte abgefangen werden. Kein Produktivsystem darf ohne TLS betrieben werden.
- TLS 1.2 als Minimum, TLS 1.3 bevorzugt
- Let's Encrypt für kostenlose Zertifikate
- HSTS-Header setzen (erzwingt HTTPS)
[BE][lockSSL] = truein TYPO3-Konfiguration
Dateiberechtigungen
Korrekte Berechtigungen verhindern unbefugten Zugriff:
| Dateityp | Berechtigung | Begründung |
|---|---|---|
| Verzeichnisse | 755 | Lesen/Ausführen für alle, Schreiben nur Owner |
| PHP-Dateien | 644 | Kein Ausführen direkt, nur über Webserver |
| Konfigurationsdateien | 640 | Kein Zugriff für "others" |
| Upload-Verzeichnisse | 775 | Webserver muss schreiben können |
HTTP-Zugriffsbeschränkung
Blockieren Sie den Zugriff auf sensible Dateien und Verzeichnisse:
Directory Indexing deaktivieren
Automatische Verzeichnislistung muss deaktiviert sein, um Informationslecks zu verhindern:
Security Headers
HTTP-Security-Header sind eine wichtige Verteidigungsebene gegen verschiedene Angriffe. Sie werden vom Webserver gesendet und instruieren den Browser zu sicherem Verhalten.
Empfohlene Header
| Header | Wert | Schutz gegen |
|---|---|---|
Strict-Transport-Security | max-age=31536000; includeSubDomains | Downgrade-Angriffe, SSL-Stripping |
X-Frame-Options | SAMEORIGIN | Clickjacking |
X-Content-Type-Options | nosniff | MIME-Type-Sniffing |
Referrer-Policy | strict-origin-when-cross-origin | Informationslecks |
Permissions-Policy | geolocation=(), microphone=() | Ungewollte API-Nutzung |
Content-Security-Policy | Projekt-spezifisch | XSS, Code-Injection |
Konfiguration
CSP kann bei falscher Konfiguration die Website funktionsunfähig machen. Beginnen Sie mit Content-Security-Policy-Report-Only und prüfen Sie die Browser-Konsole auf Verstöße, bevor Sie den Header scharf schalten.
Überprüfung
Testen Sie Ihre Security Headers mit diesen Tools:
- securityheaders.com – Schnelle Analyse
- Mozilla Observatory – Umfassender Sicherheitscheck
- Browser DevTools → Network → Response Headers
Datenbank-Sicherheit
phpMyAdmin, Adminer und ähnliche Tools dürfen nicht auf Produktivsystemen installiert sein. Sie vergrößern die Angriffsfläche erheblich.
Backup-Strategie
Die offizielle TYPO3-Dokumentation empfiehlt eine gestaffelte Backup-Strategie:
| Frequenz | Composer-Installation (v12+) | Klassisch (Legacy) | Aufbewahrung |
|---|---|---|---|
| Täglich | Datenbank + fileadmin/ | Datenbank + fileadmin/ | 7 Tage |
| Wöchentlich | DB + fileadmin/ + config/ + var/log/ | DB + fileadmin/ + typo3conf/ + uploads/ | 4 Wochen |
| Monatlich | Vollständig (+ composer.lock) | Vollständig (inkl. typo3/ Core) | 6 Monate |
| Jährlich | Vollständiges Archiv | Vollständiges Archiv | Mehrere Jahre |
Composer-Installation (empfohlen):
config/– Systemkonfiguration (settings.php,sites/)fileadmin/– Benutzer-Uploads (FAL)var/log/– Logs für Forensik (Cache ist regenerierbar)composer.json+composer.lock– Code ist reproduzierbar!
Klassische Installation (Legacy):
typo3conf/– Konfiguration + Extensionsfileadmin/+uploads/– Benutzer-Dateientypo3/– Core-Dateien
- Niemals im Document Root speichern – Backups dürfen nicht öffentlich erreichbar sein
- Verschlüsselung – Backups enthalten sensible Daten (Passwort-Hashes, Kundendaten)
- Offsite-Kopie – Mindestens eine Kopie extern speichern (Ransomware-Schutz)
Ein Backup ist nur so gut wie der letzte erfolgreiche Restore-Test. Testen Sie die Wiederherstellung regelmäßig in einer separaten Umgebung und prüfen Sie auf fehlende Daten.
Integration & Konfiguration
Integrator:innen konfigurieren TYPO3 und sind verantwortlich für sichere Systemeinstellungen.
Install Tool Absicherung
Das Install Tool ermöglicht tiefgreifende Systemänderungen und erfordert besonderen Schutz:
- ENABLE_INSTALL_TOOL-Datei in
var/transient/(Composer) odertypo3temp/var/transient/(klassisch) - Separates Passwort (nicht das Admin-Passwort!)
- Auto-Löschung nach 60 Minuten Inaktivität
Der Inhalt KEEP_FILE in der Enable-Datei verhindert die automatische Löschung und ist in Produktionsumgebungen streng verboten.
Application Context (TYPO3_CONTEXT)
Der Application Context ermöglicht unterschiedliche Konfigurationen für verschiedene Umgebungen. Dies ist kritisch für die Sicherheit, da Debugging-Optionen nur in Entwicklungsumgebungen aktiv sein sollten.
Empfohlene Kontexte
| Context | Zweck | Debugging | Caching |
|---|---|---|---|
Production | Live-System | Deaktiviert | Aktiv |
Production/Staging | Staging-Server | Deaktiviert | Aktiv |
Development | Entwicklung | Aktiviert | Reduziert |
Development/Local | Lokale Entwicklung | Aktiviert | Minimal |
Testing | Automatisierte Tests | Aktiviert | Deaktiviert |
Konfiguration
Context-spezifische Konfiguration
TYPO3 lädt automatisch zusätzliche Konfigurationsdateien basierend auf dem Context:
Ohne gesetzten TYPO3_CONTEXT verwendet TYPO3 den Production-Context als Default. Stellen Sie dennoch sicher, dass die Variable explizit gesetzt ist, um Fehler zu vermeiden.
Offizielle Dokumentation: Application Context
Lokale Entwicklung mit DDEV
DDEV ist die empfohlene Entwicklungsumgebung für TYPO3-Projekte. Die containerbasierte Lösung bietet erhebliche Sicherheitsvorteile gegenüber klassischen LAMP-Setups.
Sicherheitsvorteile
- Isolierte Umgebung – Projekte laufen in separaten Containern
- Automatische HTTPS – Lokale SSL-Zertifikate out-of-the-box
- Konsistente Umgebung – Identische PHP-Version wie Production
- Keine lokale Installation – Kein PHP/MySQL auf dem Host nötig
Entwickler-Produktivität
- Schnelle Einrichtung –
ddev config && ddev start - PHP-Version wechseln – Einfach in
.ddev/config.yaml - Integrierte Services – Redis, Solr, MailHog, Elasticsearch
- Composer & Node – Vollständig integriert
Committen Sie .ddev/config.yaml ins Repository. So hat jedes Teammitglied automatisch die identische Entwicklungsumgebung – keine "Works on my machine"-Probleme.
Globale Konfiguration
Alle sicherheitsrelevanten Einstellungen in config/system/settings.php bzw. config/system/additional.php:
Diese drei Einstellungen müssen in jeder Produktionsumgebung korrekt gesetzt sein:
trustedHostsPattern– Regex für erlaubte Domains (nicht.*!)displayErrors = 0– Keine FehlerausgabedevIPmask = ''– Keine Debug-IPs
Benutzer & Rechte
Prinzip der geringsten Rechte (PoLP)
Jede:r Benutzer:in erhält nur die minimal notwendigen Berechtigungen:
- Redakteur:innen: Nur Zugriff auf relevante Seitenbäume und Dateibereiche
- Administrator:innen: Kein System Maintainer-Status, wenn nicht benötigt
- System Maintainers: Auf absolute Minimum beschränken (1-2 Personen)
Multi-Faktor-Authentifizierung (MFA)
MFA muss für alle Konten mit administrativen Rechten verpflichtend aktiviert werden. TYPO3 unterstützt TOTP und Recovery Codes nativ.
Extension-Management
- Nur Extensions aus vertrauenswürdigen Quellen (TER, Packagist)
- Regelmäßige Updates aller Extensions
- Ungenutzte Extensions entfernen – jede Extension erweitert die Angriffsfläche
- Security Bulletins auch für Extensions beachten
Das TYPO3 Security Team arbeitet reaktiv, nicht proaktiv:
- Keine automatische Prüfung – Nur ein kleiner Prozentsatz der TER-Extensions wurde vom Security Team geprüft (Quelle)
- Nur bei Meldung – Das Team wird erst aktiv, wenn jemand eine Schwachstelle an security@typo3.org meldet
- Nur TER-Extensions – Security Bulletins werden ausschließlich für Extensions im TER veröffentlicht (Quelle)
Extensions aus privaten Repos, GitHub oder nicht-TER Packagist-Paketen erhalten niemals Security Bulletins vom TYPO3 Security Team. (Quelle)
Das bedeutet: Ihr Entwicklungsteam trägt die volle Verantwortung für Security-Audits, Vulnerability-Monitoring und Patch-Management dieser Extensions.
Der Prozess nach einer Meldung
Wenn eine Sicherheitslücke in einer TER-Extension gemeldet wird, folgt das Security Team der Extension Security Policy:
- Benachrichtigung – Security Team informiert den Extension-Entwickler vertraulich
- Reaktion erforderlich – Entwickler muss zeigen, dass die Extension aktiv gepflegt wird
- Fix bereitstellen – Patch wird entwickelt und in einem privaten Repository getestet
- Koordinierte Veröffentlichung – Security Bulletin + neue Extension-Version gleichzeitig
Bei Nicht-Reaktion: Das Security Team veröffentlicht ein Removal Bulletin und die Extension wird aus dem TER entfernt. (Quelle)
Sicherheitswarnungen nach Login
TYPO3 zeigt nach dem Backend-Login Sicherheitswarnungen an. Diese ernst nehmen und zeitnah beheben:
- Veraltete Core-Version
- Unsichere Extensions
- Fehlende Konfiguration
Extension-Entwicklung
Entwickler:innen tragen besondere Verantwortung, da unsicherer Code die gesamte Installation gefährdet.
"Never trust user input" – Alle Daten von außen (GET, POST, Cookies, Header) sind potenziell bösartig und müssen validiert werden.
Input-Validierung
Validieren Sie alle Eingaben serverseitig:
- Typ-Prüfung: Integer, String, Boolean
- Längen-Limits: Maximale Zeichenanzahl
- Whitelist: Nur erlaubte Werte akzeptieren
- Encoding: UTF-8 erzwingen
SQL-Injection verhindern
XSS verhindern
Fluid escaped Ausgaben standardmäßig. Ausnahmen beachten:
| Kontext | Schutz |
|---|---|
| Fluid-Variablen in HTML | Automatisch escaped |
<f:format.raw> | Kein Escaping – niemals für Benutzerdaten! |
| ViewHelper-Argumente | Nicht escaped – manuell escapen! |
| JavaScript-Kontext | JSON.stringify() oder htmlspecialchars() |
Extbase-Sicherheit
- Property Mapping: Nur explizit erlaubte Properties akzeptieren
- __trustedProperties: Verhindert Mass Assignment durch kryptografische Validierung
- Validierung: Extbase Validators für Domain-Objekte nutzen
Redakteur-Sicherheit
Auch Redakteur:innen können durch unsicheres Verhalten Sicherheitslücken öffnen.
Sichere Content-Eingabe
- Rich-Text-Editor verwenden statt direktem HTML
- Keine unbekannten Embeds (YouTube, Twitter etc.) von unsicheren Quellen
- Links prüfen vor dem Setzen – keine Redirects zu unbekannten Domains
- Keine Skripte in RTE einfügen (werden oft geblockt, aber nicht immer)
Upload-Richtlinien
Erlaubt
- Bilder: jpg, png, gif, svg, webp
- Dokumente: pdf, docx, xlsx, pptx
- Archive: zip (nach Prüfung)
Verboten
- Ausführbare: php, exe, sh, bat
- Web-Dateien: html, htm, js
- Server-Dateien: htaccess, conf
- Dateinamen prüfen: Keine Sonderzeichen, die Injection ermöglichen
- Dateigröße beachten: Verdächtig große Dateien melden
- Herkunft verifizieren: Keine Dateien aus unbekannten Quellen hochladen
Phishing-Awareness
- Niemals Zugangsdaten per E-Mail teilen
- URL prüfen vor Eingabe von Passwörtern
- Verdächtige E-Mails an IT melden
- Bei Unsicherheit: Nachfragen statt Klicken
Nach einem Angriff
Trotz aller Vorsichtsmaßnahmen kann eine Kompromittierung nie vollständig ausgeschlossen werden. Ein klarer Notfallplan ist essentiell.
Anzeichen erkennen
Offensichtlich
- Website zeigt fremde Inhalte (Defacement)
- Weiterleitungen zu unbekannten Domains
- Suchmaschinen-Warnungen ("Diese Website könnte gehackt sein")
- Unbekannte Backend-Benutzer
Subtil
- Ungewöhnlich hoher Traffic/Serverlast
- Spam-E-Mails vom Server
- Neue Dateien in Upload-Verzeichnissen
- Geänderte Zeitstempel bei Core-Dateien
Sofortmaßnahmen
Website offline nehmen
Beweissicherung
Zugangsdaten ändern
Analyse durchführen
Wiederherstellung
Ein kompromittiertes System manuell zu "säubern" ist extrem fehleranfällig. Backdoors werden oft übersehen und ermöglichen erneuten Zugriff.
Empfohlenes Vorgehen:
- Sauberes Backup identifizieren (vor dem Angriff erstellt)
- Frische Installation auf bereinigtem Server
- Datenbank aus Backup wiederherstellen
- TYPO3 und Extensions auf neueste Versionen aktualisieren
- Sicherheitslücke schließen, die den Angriff ermöglichte
- Alle Passwörter erneuern
- Erst dann online gehen
Präventive Maßnahmen nach Wiederherstellung
- Schwachstelle dokumentieren und beheben
- Sicherheitsaudit durchführen
- Monitoring intensivieren
- Team schulen
- Incident-Response-Plan aktualisieren
Composer & Code-Integrität
Die Composer-Installation ist der einzige empfohlene Weg für produktive TYPO3-Systeme. Der klassische Modus sollte nur für Testzwecke verwendet werden.
Sicherheitsvorteile
| Aspekt | Composer | Klassisch |
|---|---|---|
| Paketverifizierung | Checksums geprüft | Manuell (wenn überhaupt) |
| Update-Sicherheit | Atomare Updates | Code-Leichen möglich |
| Dependency Audit | composer audit | Nicht verfügbar |
| Reproduzierbarkeit | composer.lock | Nicht gegeben |
| Document Root | Separiert | Alles öffentlich |
Sichere Update-Strategie
Zusammenfassung
Composer nutzen
Persönliche Empfehlung: Installationsweg für verifizierte Pakete und sichere Updates
Sofort updaten
Security Releases innerhalb von 24 Stunden einspielen
Defense in Depth
Mehrere Sicherheitsebenen: Server, Anwendung, Benutzer, Prozesse
Ressourcen
- TYPO3 Security Guide – Offizielle Dokumentation
- TYPO3 Security Team – Schwachstellen melden
- Security Advisories – Aktuelle Warnungen
- ELTS-Programm – Extended Long Term Support
Kontaktieren Sie uns für ein unverbindliches Gespräch.
E-Mail: office@webconsulting.at