Matthias Gläßner – Senior TYPO3 Architekt

Security Audit · OWASP · Härtung · CSP/HSTS · Rechte · Monitoring

TYPO3 Security Audit Checkliste:
konkrete Prüfpunkte für stabile Sicherheit

Diese Checkliste hilft Ihnen, ein TYPO3 System systematisch zu prüfen – vom Patch-Stand über Rechte und Uploads bis zu Security Headers, Logging und Incident-Readiness. Ziel: Risiken priorisieren und schnell Maßnahmen ableiten – statt „Security als Bauchgefühl“.

Quick Wins + High-Risk Checks Für IT, Security & Webteams Enterprise & Public Sector geeignet
Security Audit & Härtung anfragen Notfall-Checkliste lesen

Hinweis: Diese Liste ersetzt keinen Pentest – sie ist ein pragmatischer Audit-Rahmen für Priorisierung & Maßnahmen.

Schnellstart: die 10 wichtigsten Checks (erst mal das Risiko senken)

Wenn Sie wenig Zeit haben: starten Sie mit diesen Punkten. Sie reduzieren typische Angriffsflächen (und sparen später echte Notfallkosten).

  1. Core & Extensions patchen (auch Abhängigkeiten/Composer).
  2. Backend-Login absichern (2FA, Rate Limits, ggf. IP-Schutz).
  3. Administrator-Rechte minimieren (Least Privilege).
  4. Security Headers: CSP (mindestens „report-only“ start), HSTS, X-Frame-Options/Frame-Ancestors.
  5. Uploads prüfen (Dateitypen, Malware-Scan, Pfad-/Ausführbarkeit).
  6. Logs & Alerts: 500er, Login-Anomalien, Upload-Auffälligkeiten.
  7. Staging & Deployments: reproduzierbar, keine „Hotfixes“ live.
  8. Secrets: keine Keys im Repo, kein Klartext in Configs.
  9. Backup & Restore testen (Restore-Übung, nicht nur „Backup vorhanden“).
  10. Incident-Plan: Wer macht was bei P1? Kontakte, Zugang, Entscheidungspfad.

Security Audit Checkliste (vollständig) – nach Bereichen

Die folgenden Blöcke sind so aufgebaut, dass Sie sie im Audit direkt abhaken können. Wichtig: Nicht alles ist „kritisch“. Entscheidend ist Priorisierung nach Ihrem Systemtyp.

1) Patch-Stand & Lifecycle

  • • TYPO3 Core: Version innerhalb LTS-Support?
  • • Install Tool / Composer Lock: reproduzierbarer Build?
  • • Extensions: Update-Stand, bekannte CVEs, „abandonware“?
  • • PHP Version: supported + Security Updates aktiv?
  • • Third-Party libs: composer audit / Sicherheitschecks
  • • Release-Prozess: Plan für regelmäßige Patch-Zyklen

Ziel: Patch-Backlog vermeiden – Security entsteht durch Routine, nicht durch Einmalaktionen.

2) Auth, Backend & Redaktionsschutz

  • • Backend: 2FA aktiv (Admins/Editoren nach Bedarf)
  • • Rate Limiting / Brute-Force Schutz vorhanden?
  • • Admin-Accounts: minimal, persönliche Konten, kein „shared admin“
  • • Rollen/Permissions: Least Privilege umgesetzt?
  • • SSO (SAML/OAuth): sauber konfigurierte Claims & Gruppenmapping
  • • Session Handling: Cookies, Secure/HttpOnly/SameSite

Typischer Risiko-Treiber: zu viele Rechte + schwach abgesicherte Admin-Logins.

3) Server, Hosting & Infrastruktur

  • • Betriebssystem: Updates/Kernel Patches, Hardening Baseline
  • • Webserver: TLS Settings, moderne Ciphers, Redirect HTTP→HTTPS
  • • PHP-FPM: Isolation, expose_php off, sensible defaults
  • • Dateirechte: Webroot minimal, „write“ nur wo nötig
  • • Separate DB/User: minimal privileges, keine root credentials
  • • Firewall/WAF/CDN: sinnvoll eingesetzt (je nach Risiko)

4) Security Headers & Browser Hardening

  • • HSTS aktiv (inkl. preload-Strategie wenn passend)
  • • Content Security Policy (CSP) – start mit Report-Only
  • • Frame-Ancestors / Clickjacking Schutz
  • • Referrer-Policy, Permissions-Policy sinnvoll gesetzt
  • • Mixed Content vermeiden (HTTP Assets)
  • • Cookie Flags (Secure/HttpOnly/SameSite) geprüft

CSP lohnt sich besonders bei Portalen mit vielen Dritt-Skripten.

5) Uploads, Medien & Dateisicherheit

  • • Erlaubte Dateitypen restriktiv (Whitelist)
  • • Ausführbarkeit von Uploads verhindern (no exec)
  • • SVG Handling: sanitized oder deaktiviert (Risiko!)
  • • Malware-Scan (je nach Kritikalität / Compliance)
  • • FAL/Storage: öffentliche vs. private Dateien getrennt
  • • Zugriff auf geschützte Downloads abgesichert

6) Extensions, Custom Code & typische Risiken

  • • Ungepflegte Extensions identifizieren (Risiko & Ersatzplan)
  • • Zugriffskontrollen in eigenen Plugins/Modules geprüft
  • • SQL Injection / XSS Risiken: saubere Query APIs, Escaping
  • • File Access: Pfadvalidierung, keine „open file“ ohne Checks
  • • APIs: Auth, Rate Limiting, Input Validation
  • • Deprecations/Upgrade-Fähigkeit als Security-Faktor

7) Datenschutz & Datenflüsse (DSGVO)

  • • Tracking/Third-Party Scripts: Consent & Zweckbindung
  • • Logfiles: IP/Personenbezug, Aufbewahrung & Zugriff
  • • Formulare: Spam-Schutz, Validierung, Datenminimierung
  • • Zugriff auf personenbezogene Daten: Rollenmodell
  • • AVV/Verarbeitungsverzeichnis: Prozesse abgestimmt
  • • Data Export/Deletion: Prozesse klar geregelt

8) Logging, Monitoring & Alarmierung

  • • Zentralisierte Logs (Webserver, PHP, TYPO3)
  • • Alerts auf 5xx, Login-Spikes, Upload-Auffälligkeiten
  • • Fehler sichtbar: Dashboards statt „nur Logdateien“
  • • Critical Jobs: Scheduler/Queues überwacht
  • • Incident Playbooks / Runbooks vorhanden?
  • • Zugriffe/Änderungen auditierbar (je nach Compliance)

9) Deployment, CI/CD & Supply Chain

  • • Deployments: reproduzierbar, versioniert, kein „Handarbeit live“
  • • Secrets: Vault/Secret-Store, keine Keys im Repo
  • • Build Pipeline: Composer Lock, Checks, Security Scans
  • • Code Reviews (4-Augen-Prinzip) für kritische Bereiche
  • • Zugriff auf Pipelines: Rollen & Least Privilege
  • • Abhängigkeiten: Updates geplant statt „random“

10) Backup, Restore & Incident Readiness

  • • Backups: DB + Files + Configs (vollständig?)
  • • Restore-Test: regelmäßig wirklich geübt
  • • RPO/RTO definiert (wie viel Datenverlust / Zeit akzeptabel?)
  • • Zugriff im Notfall: Verantwortliche & Zugänge
  • • Notfall-Kommunikation: intern + extern geregelt
  • • Lessons Learned: nach Incidents verbessern

Backup ohne Restore-Test ist Hoffnung – kein Plan.

Priorisierung: wie Sie aus der Checkliste eine Roadmap machen

Security wird machbar, wenn Sie Maßnahmen nach Risiko und Aufwand sortieren. Ein gutes Vorgehen ist: erst Angriffsflächen schließen, dann Prozesse stabilisieren.

Rot (sofort)

Ungepatchtes Core/Extensions, unsicherer Admin-Login, kritische Upload-Risiken, offene Admin-Accounts.

Orange (kurzfristig)

Logging/Alerts, CSP/Headers, Least Privilege, Secrets/Config Hygiene, Staging-Routine.

Gelb (mittelfristig)

Pipeline Security, Runbooks, regelmäßige Restore-Übungen, strukturierte Reports & Governance.

Blau (nice to have)

Zusätzliche Härtungsmaßnahmen, WAF Fine-Tuning, zusätzliche Dashboards & Komfort-Optimierungen.

Tipp: Security & Wartung zusammendenken

Viele Sicherheitslücken entstehen nicht durch „Hacker-Magie“, sondern durch veraltete Komponenten, fehlende Routine und unklare Zuständigkeiten. Ein Wartungsvertrag mit SLA ist deshalb oft der schnellste Weg zu dauerhaft besserer Security.

→ Wartungsvertrag & SLA Kosten verstehen

Häufige Fragen zum TYPO3 Security Audit

Müssen wir für das Audit direkte Serverzugänge geben? ›
Nicht zwingend. Für viele Checks reichen zunächst Versionsstände, Konfig-Auszüge, CI/CD-Infos und Logs. Für ein vollständiges Audit (Server-Härtung, Rechte, Monitoring) ist Zugriff allerdings sehr hilfreich.
Wie wird das Ergebnis dokumentiert? ›
Idealerweise als Roadmap mit Risiko-Stufen, konkreten Maßnahmen und Aufwandsschätzung (S/M/L) – plus Quick Wins, die sofort umgesetzt werden können.
Ist CSP nicht „zu aufwendig“? ›
CSP kann komplex sein, wenn viele Dritt-Skripte im Spiel sind. Daher: erst „report-only“ starten, Reports auswerten, schrittweise härten. Das bringt langfristig viel Sicherheit gegen XSS.

Sicherheit für TYPO3 planbar machen

Wenn Sie die Checkliste nicht nur abhaken, sondern daraus eine umsetzbare Roadmap machen wollen: Ich unterstütze bei Audit, Priorisierung, Härtung und dem Aufbau stabiler Betriebsroutinen.

Security Audit anfragen Security & DSGVO Artikel

Unverbindlich · vertraulich · Remote DACH · NDA/AVV möglich