- TYPO3-Version prüfen: Läuft eine aktive LTS (z.B. 12 LTS oder 13 LTS)? End-of-Life-Versionen sofort migrieren.
- Composer-basiertes Setup einsetzen – kein manuelles Hochladen mehr.
- Wöchentliches Scan-Fenster für composer outdated und composer audit definieren.
- Alle TYPO3-Security-Advisories abonnieren (typo3.org/help/security-advisories).
- PHP-Version: TYPO3 unterstützte PHP-Version verwenden, keine EOL-PHP wie 7.4 oder älter.
Praxis-Guide 2025
Die ultimative TYPO3 Sicherheitscheckliste für 2025
8 Kapitel, über 40 konkrete Prüfpunkte. Dieser Leitfaden zeigt Site-Ownern, Agenturen und IT-Verantwortlichen, wie sie eine TYPO3-Installation systematisch absichern – von Updates über Extension-Audits bis hin zu Backup- und Monitoring-Strategien.
1. TYPO3-Core & Extensions aktuell halten
Die häufigste Einfallsquelle bei kompromittierten TYPO3-Installationen ist ein veralteter Core oder ein ungepatchtes Drittanbieter-Extension. Die TYPO3-Association veröffentlicht Security Bulletins regelmäßig – wer sie nicht zeitnah einspielt, läuft auf bekannten CVEs.
2. Extension-Hygiene & TER-Reviews
Jede installierte Extension erweitert die Angriffsfläche. In Audits finden wir regelmäßig verwaiste Extensions ohne Maintainer, Forks aus Github ohne Reviews oder uralte Versionen, die niemand mehr aktualisiert.
- Inventur: Alle aktiven Extensions auflisten (Extension Manager bzw. composer.json).
- Letztes Release-Datum prüfen – alles über 18 Monate ohne Update kritisch hinterfragen.
- Verwaiste oder ungenutzte Extensions deaktivieren und deinstallieren – nicht nur ausblenden.
- Custom Extensions auf eval(), unserialize() und direktes SQL ohne QueryBuilder prüfen.
- Bei Closed-Source-Extensions: Maintainer-SLA und Security-Kontakt dokumentieren.
3. Backend-Accounts & Passwörter
Ein einziger Admin-Account mit „Sommer2024!" reicht aus, um eine komplette Installation zu verlieren. Backend-Hygiene ist die billigste und wirkungsvollste Härtungsmaßnahme.
- Alle Backend-User auflisten, deaktivierte und ehemalige Mitarbeiter konsequent löschen.
- Zwei-Faktor-Authentifizierung (z.B. ext: mfa_webauthn) für alle Admins erzwingen.
- Mindestpasswortlänge 12+ Zeichen, Wiederverwendung blockieren (be_secure_pw o.ä.).
- Admin-Rechte auf das Notwendige reduzieren – Redakteure brauchen selten Install-Tool-Zugriff.
- Install-Tool-Passwort separat, zufällig generiert, im Passwortmanager.
- Backend-URL nicht /typo3 sondern via Webserver-Aliasing erschweren (Security by Obscurity ergänzt, ersetzt aber nichts).
4. Datei- & Verzeichnisrechte
Falsch gesetzte Rechte sind ein klassisches Audit-Finding: Webserver-User mit Schreibrechten in sensitiven Pfaden, weltlesbare .env-Dateien, oder ein /typo3temp, das via HTTP erreichbar ist.
- Owner und Gruppe konsequent setzen, kein 777 irgendwo im Projekt.
- .env, LocalConfiguration.php und Backups niemals per HTTP ausliefern.
- /fileadmin/_temp_ und /typo3temp/ regelmäßig auf hochgeladene PHP-Dateien prüfen.
- Upload-Whitelist im Install-Tool eng halten – kein .phtml, .htaccess, .svg-Upload für Redakteure.
- Open_basedir und disable_functions im PHP-Pool restriktiv konfigurieren.
5. Server- & PHP-Konfiguration
TYPO3-Sicherheit endet nicht im CMS – Webserver, PHP-FPM, OS und TLS gehören zwingend dazu.
- HTTPS erzwingen (HSTS aktiv, mind. 6 Monate, idealerweise mit Preload).
- Security-Header setzen: CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
- Server-Version-Banner deaktivieren (ServerTokens Prod, expose_php = Off).
- Fail2Ban oder vergleichbares gegen Backend-Bruteforce auf /typo3/.
- WAF vorschalten (z.B. ModSecurity OWASP CRS oder Cloud-WAF) – mindestens im Detection-Mode.
- OS-Pakete monatlich patchen, unbeaufsichtigte Sicherheitsupdates aktivieren.
6. Datenbank & Backups
Ohne funktionierendes Backup ist jeder Vorfall existenzbedrohend. „Wir machen Backups" reicht nicht – sie müssen getestet, verschlüsselt und off-site sein.
- Tägliche Datenbank- und Filesystem-Backups, mindestens 30 Tage Retention.
- Backup-Wiederherstellung mindestens quartalsweise testen – nicht nur Existenz prüfen.
- Backups verschlüsselt und auf separatem Storage (3-2-1-Regel).
- DB-User für TYPO3 mit minimalen Rechten – kein DROP/CREATE auf Produktiv-DB.
- Sensitive Felder (be_users.password, fe_users.password) – Hash-Algorithmus prüfen (Argon2id empfohlen).
7. Monitoring, Logs & Incident Response
Der durchschnittliche Angriff bleibt Wochen unentdeckt. Logging und Alerting verkürzen diese Zeitspanne dramatisch – und sind im Ernstfall Ihre wichtigste Evidenzquelle.
- TYPO3 sys_log und sys_history zentralisiert speichern (mind. 90 Tage).
- Webserver Access- und Error-Logs in ein SIEM oder mindestens Loki/ELK leiten.
- Alerts auf: fehlgeschlagene Backend-Logins, neue Admin-User, Änderungen am Install-Tool.
- Schriftlicher Incident-Response-Plan: Wer entscheidet, wer kommuniziert, wer technisch handelt?
- Externe Notfall-Kontakte (Hoster, Security-Dienstleister) dokumentiert und griffbereit.
8. Regelmäßiger TYPO3 Security Audit
Eine Checkliste ist ein Snapshot. Sicherheit ist ein Prozess. Mindestens einmal jährlich – bei stark frequentierten oder regulierten Sites halbjährlich – sollte ein strukturierter Audit stattfinden.
- Externer Code- und Konfigurations-Review (mindestens jährlich).
- Automatisierte Vulnerability-Scans (z.B. wöchentlich gegen Staging und Produktiv).
- Pen-Test alle 24 Monate oder bei wesentlichen Releases.
- Dokumentation versionieren – jeder Audit-Bericht muss vergleichbar sein.
- Findings in ein Ticketsystem mit Deadlines überführen, nicht in eine PDF-Schublade.