README

Contao Security Suite

Contao-native Sicherheitsüberwachung, ‑Audit und ‑Härtung mit einer modernen Backend-Sicherheitskonsole.

Deutsch (primär) · English version

Projektübersicht

Die Contao Security Suite ist ein Contao-Bundle, das eine Backend-Sicherheitskonsole für eine Contao-Installation bereitstellt. Sie beantwortet zwei Fragen gleichzeitig:

Sicherheitslage – ist diese Installation sicher konfiguriert?
Sicherheitsaktivität – ist etwas Auffälliges geschehen?

Dazu führt sie einen Satz lokaler Sicherheitsprüfungen aus, berechnet daraus einen Sicherheitsscore, verwaltet Feststellungen („Findings") über ihren gesamten Lebenszyklus, zeichnet Sicherheitsereignisse auf, wertet die Backend-Anmeldeaktivität aus und korrigiert – in der Pro-Edition – was sie sicher selbst korrigieren kann: Ein-Klick-Behebung mit Vorschau, Verifizierung und Rollback, automatische IP-Sperrung für die Backend-Anmeldung (Aktiver Schutz) und Quarantäne für exponierte oder verdächtige Dateien, plus Pfadsondierungserkennung, Quellenreputation, ausgewählte Frontend-Drosselung, Upload-Prävention und gebündelte Sicherheitsbenachrichtigungen in Stage 2. Stage 3 ergänzt adaptive lokale Anmelde-Challenges, sicherheitsbewusste Backend-Sitzungen und einen vertrauensnetz-basierten Notfall-Sperrmodus. Stage 4 ergänzt optionale externe Durchsetzung (Cloudflare), Fail2ban-Signale, gecachte Bedrohungsdaten, Pfad-Härtung, TLS-/Zertifikatsprüfung und sichere Vorfallnachweise. Diese Funktionen ersetzen keine Server- oder Netzwerk-Firewall.

Eigenschaft	Wert
Paket	`vtinnovations/contao-security-suite`
Typ	`contao-bundle`
Namespace	`Vtinnovations\ContaoSecuritySuite`
Lizenzmodell	proprietär, Nicht lizenziert / Free / Pro (V‑T.ONE)
Website	https://www.v-t.one

Aktueller Implementierungsstatus

Alle zwölf Bereiche der Suite sind als echte, funktionsfähige Module umgesetzt. Der Sicherheitsscore, die Findings, die Ereignisse, die Login-Auswertung und die Dashboard-Kacheln stammen aus tatsächlich erhobenen Daten – nicht aus Beispieldaten. Die Analyse-Engine ist in der Free- und in der Pro-Edition aktiv; die Lizenzierung schaltet den Zugriff auf die Bereiche außer dem Dashboard sowie sämtliche verändernden Aktionen frei, nicht die Analyse selbst.

Das Repository trägt die Version dev-main und ist nicht getaggt. Es wird als Git- bzw. Pfad-Repository oder über den Contao Manager aus dem V‑T.ONE-Paketkanal installiert.

Unterstützte Versionen

Komponente	Anforderung
PHP	`^8.1`
Contao	`^5.3` (`contao/core-bundle`)
Symfony	`^6.4 \|\| ^7.0` (durch Contao vorgegeben)
Doctrine DBAL	`^3.6 \|\| ^4.0`
Zwei-Faktor-Authentifizierung	`scheb/2fa-bundle` `^6 \|\| ^7 \|\| ^8`
Datenbank	die von Contao verwendete MySQL-/MariaDB-Verbindung

Systemvoraussetzungen

Eine lauffähige Contao-Installation (^5.3; das Lizenzfeld unter Contao → Einstellungen ist gegen die Quellen von Contao 5.7.12 geprüft, die Test-Suite läuft auf diesem Release; 5.3 ist durch die deklarierte Constraint abgedeckt, wurde hier aber nicht erneut ausgeführt) mit Datenbankzugriff.
Composer für die Installation und Aktualisierung des Bundles.
Schreibrechte auf das Contao-Projektverzeichnis var/ – insbesondere var/contao_security_suite/, wo die Suite private Laufzeitdaten außerhalb des öffentlichen Web-Roots ablegt.
Für geplante Scans: ein eingerichteter Contao-Cron (contao:cron, per System-Cron oder Weblauf).
Für die Schwachstellenprüfung der Erweiterungen: das PHP-Kommando composer muss auf dem Server ausführbar sein (die Suite ruft composer audit über einen Unterprozess auf).
Optional ein Symfony-HTTP-Client. Fehlt er, funktioniert die Suite weiter; Lizenz-Operationen, die den Anbieter kontaktieren, melden dann „Dienst nicht erreichbar", ohne den gespeicherten Zustand zu verändern.

Installation

composer require vtinnovations/contao-security-suite

Anschließend die Datenbank aktualisieren und den Cache leeren:

vendor/bin/contao-console contao:migrate
vendor/bin/contao-console cache:clear

Über den Contao Manager wird das Paket wie jedes andere Bundle hinzugefügt; der Manager führt Migration und Cache-Leerung selbst aus. Die Backend-Assets (CSS/JS) werden bei der Paketinstallation nach public/bundles/vtinnovationscontaosecuritysuite/ kopiert.

Es sind keine Einträge in config/config.yaml, keine manuelle Bundle-Registrierung und keine Änderungen an .htaccess oder an der Server-Konfiguration erforderlich. Die Bundle- und Routen-Registrierung übernimmt das mitgelieferte Contao-Manager-Plugin.

Backend-Zugriff und Berechtigungen

Die Suite wird über einen einzigen Einstiegspunkt erreicht: Einstellungen → Security Suite in der linken Backend-Navigation (Contao-Kerngruppe „System"). Dieser Eintrag öffnet das Security-Dashboard. Alle weiteren Bereiche werden über die horizontale Registerkartenleiste innerhalb jeder Seite angesteuert; sie sind aus der linken Navigation ausgeblendet, aber einzeln als Backend-Module registriert und werden von Contao einzeln rechtlich geprüft.

Administratoren haben Zugriff auf alle Bereiche.
Nicht-Administratoren benötigen die jeweiligen Backend-Modulrechte (security_suite_dashboard, security_suite_issues, …), die in der Benutzergruppe freigegeben werden. Zusätzlich entscheidet die Edition (siehe unten), ob ein Pro-Bereich überhaupt geöffnet werden kann.
Jede verändernde Aktion ist ausschließlich per POST erreichbar, im Backend-Scope, mit Prüfung des Contao-Request-Tokens und einer erneuten serverseitigen Rechteprüfung.

Editionen: Nicht lizenziert, Free und Pro

Die Lizenz wird nicht im Einstellungen-Bereich der Suite eingetragen, sondern im normalen Contao-Backend unter Einstellungen → „V‑T.ONE Licence management". Dieser Abschnitt ist die gemeinsame Lizenzverwaltung aller V‑T.ONE-Produkte; die Contao Security Suite fügt dort ihr eigenes Feld hinzu, ohne die Felder anderer V‑T.ONE-Pakete zu verändern.

Edition	Voraussetzung	Verfügbar
Nicht lizenziert	kein gültiger, signierter Lizenzdatensatz (nichts eingetragen, entfernt, verfälscht, ungültig oder für eine andere Domain)	Nur die Hülle: Navigation, Dashboard-Rahmen und der Hinweis zur Lizenzierung. Kein Scan, keine Behebung, keine Pro-Bereiche, kein Aktiver Schutz, keine Exporte, keine externe Durchsetzung. „Keine Lizenz“ ist nicht Free.
Free	gültiger, signierter Free-Datensatz (oder eine abgelaufene Pro-Lizenz, die ausdrücklich den Free-Funktionsumfang weiter erlaubt)	Security-Dashboard und die vollständige Analyse dahinter: Audit-Scan, Score, Findings-Zusammenfassung, Ereignis- und Login-Übersicht auf dem Dashboard, `security-suite:scan` und die Aufbewahrungs-Crons.
Pro	gültiger, signierter Pro-Datensatz (oder ein noch nicht abgelaufener Trial), an eine hier konfigurierte Domain gebunden	Alle Bereiche, alle Detailansichten, Ereignisse, Login-Sicherheit einschließlich Aktivem Schutz (automatische IP-Sperrung, Angriffsmodus, vertrauenswürdige IPs/CIDRs), CSP, HTTP-Header, Benutzer & Zugriff, Dateien (einschließlich Quarantäne und Löschen), Erweiterungen, System, Berichte, Einstellungen sowie die gesamte Behebung (Einzel-Fix, Bereichs-„Alle beheben", Dashboard-„Alle beheben", Rollback). Die Free-Edition hat die Analyse, aber keine Behebung und keine Sperrung.

Die Lizenzprüfung erfolgt lokal und ohne Netzwerkaufruf. Schlägt die Auswertung aus irgendeinem Grund fehl, ist das Ergebnis nicht lizenziert (restriktiv bei Fehlern) – nie stillschweigend Free und nie ein defektes Backend. Ein abgelaufener oder widerrufener Pro-Datensatz fällt nur dann auf Free zurück, wenn die wirksame Lizenz dies ausdrücklich erlaubt. Beim Entfernen oder Ablaufen der Lizenz bleiben alle gespeicherten Findings, Ereignisse, Scans, Baselines, Konfigurationen und Verläufe erhalten.

Details – Lizenzzustände, Aktivierung, Aktualisierung, Entfernung und die vollständige Berechtigungsmatrix – stehen in Documentation/Lizenzierung.md.

Navigationsbereiche

Reihenfolge wie in der Registerkartenleiste der Suite:

#	Bereich	Zweck	Edition
1	Dashboard	Sicherheitsscore mit Aufschlüsselung je Domain, Kennzahlen, Aktivitätsdiagramm, Findings-nach-Schweregrad, priorisierte Probleme, Login-/Angriffsauswertung, kombinierte Zeitleiste, Status der Sicherheitskontrollen, CSP-Vorschau, Scan-Status, 30-Tage-Score-Trend.	Free und Pro
2	Sicherheitsprobleme	Priorisierte Findings-Liste mit vollständigem Lebenszyklus (offen, behoben, Behebung ausstehend, ignoriert, Risiko akzeptiert), Verlauf, Filter, Suche, Einzelbehebung und „Alle beheben".	Nur Pro
3	Ereignisse	Aufgezeichnete Sicherheitsereignis-Telemetrie (Backend-Anmeldeaktivität, Scan-Lebenszyklus, Finding-Übergänge) mit Blättern und CSV-Export der gefilterten Ansicht.	Nur Pro
4	Login-Sicherheit	Auswertung der Backend-Authentifizierung (erfolgreiche und auffällige Anmeldungen, gezielt angegriffene Konten, Quell-IP-Adressen, Trend) und Aktiver Schutz: Ratenbegrenzung, automatische temporäre IP-Sperrung, manuelles Sperren / Entsperren, vertrauenswürdige IPs und CIDR-Bereiche sowie Angriffsmodus.	Nur Pro
5	CSP	Bedienbare Konfigurationsschicht über der nativen Content-Security-Policy je Contao-Website-Root.	Nur Pro
6	HTTP-Header	Konfiguration der anwendungsseitigen Sicherheits-Header je Website-Root, Live-Prüfung der tatsächlichen Antwort, Konfliktanalyse (mit genauem Header, beobachteten Werten und wahrscheinlicher Quelle), HSTS.	Nur Pro
7	Benutzer & Zugriff	Audit der Backend-Konten, Gruppen, Rechte und 2FA-Abdeckung; die Feststellungen verlinken direkt auf den genauen Benutzer bzw. die genaue Gruppe. Nur lesend – ändert nie ein Konto.	Nur Pro
8	Dateien	Begrenzter Dateisystem-Scan, Datei-Integritäts-Baseline, öffentlich erreichbare sensible Dateien, auffällige Dateien und Rechte – mit Quarantäne (umkehrbar), Löschen (ausdrücklich bestätigt) und Rechtekorrektur.	Nur Pro
9	Erweiterungen	Composer-Inventar, `composer audit`, bekannte Schwachstellen, aufgegebene Pakete, Composer-Integrität.	Nur Pro
10	System	Audit von Contao-, Server- und Umgebungs-Sicherheitskonfiguration (PHP-Laufzeit, Session-Cookies, vertrauenswürdige Proxys, Debug-Modus, PHP-Version, Contao-Version) mit projektlokalen Behebungen (`.user.ini`, `.env.local`), wo die Anwendung sie vornehmen kann.	Nur Pro
11	Berichte	Fünf Berichtstypen aus persistierten Daten, Export als CSV (formelinjektionssicher) und als druckfreundliche HTML-Seite.	Nur Pro
12	Einstellungen	Zentraler typisierter Konfigurationsspeicher der Suite mit Prüfschema und Änderungsprotokoll.	Nur Pro

Verifizierte Modulfunktionen

Dashboard – rendert ausschließlich aus persistierten Scan-, Finding- und Ereignisdaten; Diagramme werden als Inline-SVG aus in PHP berechneter Geometrie erzeugt (keine Diagrammbibliothek, kein CDN, kein Frontend-Framework). Der Sichtbereich („24 h / 7 Tage / 30 Tage") und die Website-Auswahl bei mehreren Roots werden serverseitig ausgewertet.
Sicherheitsprobleme – jede offene Feststellung erhält je nach Behebungsklasse eine Aktion: Problem beheben (automatisch), 2FA einrichten (Verweis auf die Contao-Benutzerverwaltung) oder einen geführten Hinweis mit Direktlink. Manuelle Entscheidungen (ignorieren, Risiko akzeptieren, wieder öffnen) sind reine Statusübergänge und ersetzen nie eine echte Behebung.
Ereignisse – wiederholte identische Fehlversuchssignaturen (gleicher Typ, Ausgang, Benutzername, IP) innerhalb eines rollierenden Ein-Stunden-Fensters erhöhen einen Zähler auf einer Zeile, statt neue Zeilen anzulegen; das begrenzt das Zeilenwachstum unter Dauerlast.
Login-Sicherheit – die Erkennungsschwellen (Zeitfenster, Mindestversuche je Benutzername und je IP, verteilte Angriffe, Password-Spraying, Erfolg nach Fehlversuchen) sind in den Einstellungen konfigurierbar.
Aktiver Schutz (Pro) – eine Entscheidungs-Engine vor der Backend-Anmeldung von Contao. Sie nutzt die aufgezeichneten Fehlanmeldungs-Ereignisse (kein zweites Zählsystem) und wirkt auf die Quell-IP bzw. die Kombination aus IP und Benutzername – nie auf eine tl_user-Zeile: Ein angegriffener Benutzername erhöht den Schweregrad, sperrt das Konto aber nie. Eine bestehende Sperre – manuell oder automatisch, exakte IPv4/IPv6 oder CIDR – automatische Sperren werden bei jeder Backend-Anfrage durchgesetzt, einschließlich des Anmeldeformulars (GET), mit 429 und einer allgemeinen Meldung. Eine ausdrückliche manuelle Sperre wird zusätzlich auf Anwendungsebene bei jeder Contao/PHP-Anfrage durchgesetzt: Website-Frontend und Backend erhalten 403 bzw. die bestehende Backend-Schutzantwort; der Webserver kann direkt ausgelieferte statische Dateien weiterhin vor PHP bedienen. Die automatische Erkennung lässt sich abschalten, ohne von Hand gesetzte Sperren aufzuheben. Vorrang: Eine vertrauenswürdige Quelle umgeht automatische Sperren, eine ausdrückliche manuelle Sperre gewinnt immer (das Sperren einer vertrauenswürdigen Quelle verlangt eine Bestätigung). Quellen über dem Schwellwert werden mit 429 + Retry-After gedrosselt und – bei eingeschalteter automatischer Sperrung – temporär mit eskalierender Dauer gesperrt (erste, wiederholte, schwere Sperre). Administratoren können Quellen sperren, entsperren und als vertrauenswürdig markieren (exakte IPs oder CIDR-Bereiche, je eine Adresse oder ein Bereich pro Zeile) und den Angriffsmodus ein- und ausschalten – strengere Schwellen und längere Sperren, bis er ausgeschaltet wird. Vertrauenswürdige Quellen umgehen jeden automatischen Schutz. Solange eine Quelle gesperrt ist, erhöhen wiederholte Versuche nur einen Zähler auf ihrer Sperrzeile. Der Schutz ist ausfallsicher: Sind Lizenz, Einstellungen oder Sperrtabelle nicht verfügbar, wird die Anfrage zugelassen. Er vertraut nie eine beliebige IP, hebt nie eine Angriffssperre auf und schaltet den Angriffsmodus nie von selbst ab; der Aktive Schutz erzeugt keine Feststellungen, die Behebung schaltet ihn daher weder ein noch aus. Die Sperren liegen in tl_secsuite_ip_block.
Korrelation verteilter Angriffe (Pro) – Feindliche Backend-Fehlversuche und sensible Frontend-Beobachtungen werden in gemeinsam genutzten Datenbank-Buckets über wechselnde IPv4/IPv6-Quellen, Kontoziele, kanonische Pfadfamilien, /24- bzw. /64-Netzwerksignale und siteweite Geschwindigkeit aggregiert. Das Standard-Korrelationsfenster beträgt 60 Sekunden und ist in den Einstellungen konfigurierbar. So werden verteilte Brute-Force-, Password-Spraying- und Credential-Angriffsmuster erkannt, ohne das Zielkonto zu deaktivieren; der Schutz bleibt auf Anwendungsebene und behauptet weder eine universelle Botnet-Abwehr noch Firewall-Durchsetzung.
Stage 3: adaptive Challenge und Sitzungen (Pro) – Quellen mit erhöhtem, aber noch nicht blockwürdigem Risiko erhalten eine kurzlebige, sitzungsgebundene lokale Rechenaufgabe. Sie wird nicht bei normalen Administratoren oder vertrauenswürdigen Quellen angezeigt und ist kein dauerhafter IP-Vertrauensbeweis. Erfolgreiche Backend-Sitzungen speichern nur gehashte Sitzungs-/Browsermerkmale, IP, Zeitpunkte und ein nachvollziehbares Risikosignal. Ein IP-Wechsel allein beendet keine Sitzung; mehrere Signale erzeugen ein Ereignis „Verdächtige Sitzung“. Administratoren können andere Sitzungen beenden. Der Pro-Backend-Sperrmodus untersagt neue Backend-Anmeldungen von nicht vertrauenswürdigen Netzen, lässt bestehende Sitzungen und das öffentliche Frontend jedoch bestehen. Attack Mode verschärft die adaptive Prüfung, ist aber nicht dasselbe wie der Sperrmodus. Beides bleibt Anwendungsschutz und ersetzt keine Firewall.
CSP – die vom Administrator gewählten Presets und Eigenregeln werden zu einer Policy kompiliert, gegen Contaos eigenen CSP-Parser validiert und in das native Feld tl_page.csp geschrieben (erzwungen; cspReportOnly und cspReportLog bleiben aus). Vor jeder Änderung wird der vorherige native Zustand in tl_secsuite_csp_backup gesichert. Nonces für Inline- Skripte bleiben vollständig Contao-nativ. „Auf Website-Root anwenden“ aktiviert Contaos eigene CSP auf der Wurzel selbst (enableCsp, csp, cspReportOnly, cspReportLog – kein manuelles Anhaken nötig), schreibt genau die zuvor angezeigte Richtlinie und liest die native Zeile innerhalb der Transaktion erneut; bei Abweichung wird alles zurückgerollt und kein Erfolg gemeldet.
HTTP-Header – die konfigurierten Header werden über einen kernel.response-Listener (niemals über .htaccess) und nur dann gesetzt, wenn sie nicht bereits auf der Antwort vorhanden sind – ein von Webserver, Proxy oder anderem Bundle gesetzter Header bleibt unangetastet. HSTS sendet Contaos eigene Einstellung contao.security.hsts; ist sie aus, kann die Suite selbst ein zurückhaltendes Strict-Transport-Security senden (nur bei sicheren Anfragen, nur mit Nachweis, dass HTTPS funktioniert).
Benutzer & Zugriff – ändert nie ein Konto oder die Contao-Authentifizierung; jeder Aktionslink zeigt auf den genauen Datensatz in Contaos eigener Benutzer- bzw. Gruppenverwaltung.
Dateien – der Scan-Bereich ist begrenzt (public/, config/, templates/, die Projekt-Manifestdateien und die Bundle-Quelle) und in den Einstellungen erweiterbar bzw. einschränkbar. Die Integritäts-Baseline (tl_secsuite_file_baseline) speichert SHA-256-Hash, Größe und Änderungszeit – nie Dateiinhalte. Das Anlegen oder Aktualisieren der Baseline ist eine bewusste, bestätigte Backend-Aktion und wird als Ereignis protokolliert; ein Scan überschreibt die Baseline nie von selbst, und eine Behebung aktualisiert sie nie. Exponierte und verdächtige Dateien lassen sich nach var/contao_security_suite/quarantine/ verschieben (außerhalb jedes Document-Roots, mit Manifest, wiederherstellbar) oder löschen – Löschen ist immer eine eigene, ausdrücklich bestätigte Aktion je Datei und nie Teil von „Alle beheben“. Eine Datei wird nie geöffnet oder ausgeführt.
Erweiterungen – „Advisory-Daten nicht verfügbar" wird deutlich von „keine Schwachstellen" unterschieden. Die Netzwerknutzung von composer audit und die Einbeziehung transitiver Abhängigkeiten sind in den Einstellungen abschaltbar.
System – die Anwendung schreibt nur projektlokale Dateien: die .user.ini im Document-Root (unabhängige Direktiven bleiben erhalten, nur wo PHP sie beachtet – FPM / FastCGI) und .env.local. Eine globale php.ini, die Webserver-Konfiguration und Zertifikate werden nie angefasst. Für Werte, die sich aus der Anwendung heraus nicht ändern lassen (allow_url_include, expose_php selbst – PHP_INI_SYSTEM), nennt der Bereich die konkrete serverseitige Änderung; eine Änderung, die erst später wirkt, wird als „Behebung ausstehend“ gezeigt und behauptet keinen Erfolg, bis die Laufzeit sie beim nächsten Scan bestätigt.
Berichte – jeder Export wird als Sicherheitsereignis protokolliert; CSV-Ausgaben sind gegen Formelinjektion abgesichert; die Druckansicht enthält keine Geheimnisse.
Einstellungen – alle Schlüssel sind zentral in einem Schema deklariert und typisiert; ein Wert außerhalb seiner Grenzen wird abgewiesen. Sicherheitsrelevante Änderungen werden in tl_secsuite_setting_log protokolliert (Werte als kurze Zeichenketten, nie Geheimnisse). Ein fehlender Schlüssel bedeutet „codierter Standardwert", sodass eine frische Installation sich wie zuvor verhält.

Aktiver Schutz — Stage 2

Die Pro-Edition erkennt zentral bekannte Sondierungspfade wie /.env, /.git/, wp-login.php, phpmyadmin, Datenbank-Dumps, Backup-Archive, Shell-Dateien, Composer-Dateien und Editor-Backups. Ein einzelner normaler 404 wird nicht als Angriff gewertet; wiederholte unterschiedliche Signaturen erhöhen eine lokale, deterministische Quellenreputation mit 24-Stunden-Halbwertszeit. Backend-Fehler, Password-Spraying, Frontend-Missbrauch, geblockte Versuche und gefährliche Uploads werden in einem begrenzten Quellenprofil aggregiert statt als eine Datenbankzeile je Request gespeichert.

Passwort-Reset, Mitglieder-Login, Registrierung und identifizierbare Contao-Formulare erhalten getrennte konfigurierbare Kurzzeitfenster. Gefährliche Erweiterungen, doppelte Erweiterungen und offensichtlicher serverseitiger Inhalt werden aus dem temporären Multipart-Upload vor der Contao- Speicherung abgewiesen. Benachrichtigungen verwenden Contao's/Symfonys konfigurierten Mailer und werden mit persistentem Cooldown dedupliziert; ein Mailfehler unterbricht nie den Schutz.

Anwendungsseitiger Schutz sieht nur Requests, die PHP/Contao erreichen. Eine von nginx/Apache direkt ausgelieferte statische .zip, .env oder Backup-Datei kann nicht nachträglich abgefangen werden; dafür bleibt der Files-Scanner zuständig. Stage 2 ersetzt keine Netzwerk- oder Webserver-Firewall und vertraut nicht auf User-Agent-Namen. Details stehen in Documentation/Aktiver-Schutz-Stage2.md.

Sicherheitsprüfungen und Score

Die Suite registriert 27 unabhängige Sicherheitsprüfungen in zehn Sicherheitsdomänen. Jede Prüfung wertet ausschließlich lokalen Contao-/Anwendungszustand aus, läuft isoliert (eine fehlschlagende Prüfung stoppt die übrigen nicht) und liefert ein einzelnes Ergebnis. Der Score wird je Domäne aggregiert und daraus ein Gesamtwert von 0–100 gebildet, der ausdrücklich nur die bisher implementierten Prüfungen widerspiegelt.

Domäne	Prüfungen
Contao-Kern	1
Erweiterungen	3
Authentifizierung	2
HTTP-Header	4
CSP	3
Server-Konfiguration	6
Dateisicherheit	4
Benutzersicherheit	3
SSL/TLS	1
Überwachung	1

Die vollständige Referenz aller 27 Prüfungen – erkannter Zustand, Sicherheitsdomäne, Behebungsklasse, Verifikation und Rollback – steht in Documentation/Sicherheitspruefungen.md.

Einen Scan auslösen

Weg	Beschreibung
Backend	Schaltfläche „Audit-Scan ausführen" auf dem Dashboard (`POST`, Request-Token, erneute Rechteprüfung).
Kommandozeile	`vendor/bin/contao-console security-suite:scan`
Cron	Contao-Cron-Job, wenn geplante Scans in den Einstellungen aktiviert sind und die konfigurierte Frequenz zum ausgelösten Intervall passt.

Ein Scan liest nur Konfiguration und zeichnet Findings auf. Er ändert nichts an der Website. Er braucht eine gültige signierte Free- oder Pro-Lizenz; die Prüfung gilt für jeden Einstiegspunkt (Dashboard, Befehlszeile, geplante Scans).

Behebung von Sicherheitsproblemen (Pro)

Das Prinzip: Wenn die Security Suite den zugrunde liegenden Zustand sicher korrigieren kann, bietet Pro eine echte Aktion in der Suite. Manuell bleibt nur, was wirklich einen Menschen oder eine Infrastruktur erfordert, die die Anwendung nicht erreicht – und selbst dann nennt die Suite die genauen Schritte. Die Free-Edition hat die Analyse und keine Behebung; jeder Fix-Endpunkt erzwingt Pro auf dem Server.

Klasse	Bedeutung	Bestätigung
`AutoSafe`	folgenlose Korrektur einer Suite-eigenen Einstellung	keine
`AutoConfirm`	die Suite führt die Änderung selbst aus, sie hat aber Folgen – Vorschau, dann eine Bestätigung	eine Bestätigung (Dialog)
`Assisted`	die Suite kann es nicht selbst abschließen: genaue Schritte aus Live-Daten plus Direktlink zum genauen Datensatz	–
`Manual`	es gibt keine Behebung auf Anwendungsebene; Grund und genaue Schritte werden angezeigt	–
`None`	rein informativ	–

Eine Klasse ist nie ein Versprechen, das der Code nicht halten kann: Eine Prüfung zählt nur dann als „behebbar“, wenn ein registrierter Handler existiert und in dieser Umgebung gerade ausgeführt werden kann (seine Voraussetzungen gelten). Andernfalls wird sie ehrlich als „Prüfung erforderlich“ mit Begründung gemeldet.

Was jede Prüfung kann

Prüfung	Klasse	Aktion	Nachweis	Rollback
`suite.hardening`	AutoSafe	Stellt die Suite-Basis wieder her: Ereignis-Aufbewahrung ≥ 30 Tage; Überwachung, Erfassung von Anmeldeereignissen, Dateiscan, Dateiintegrität und Advisory-Prüfungen eingeschaltet. Fasst Aktiven Schutz, vertrauenswürdige Quellen und Sperren nie an.	Prüfung wird wiederholt	ja
`headers.security_headers`	AutoConfirm	Die empfohlene Header-Voreinstellung je Website-Root (nur gesetzt, wenn die Antwort den Header nicht bereits enthält).	Live-Antwort neu abgerufen, Prüfung wiederholt	ja
`headers.hsts`	AutoConfirm	Ein zurückhaltendes `Strict-Transport-Security` von der Suite: `max-age=15552000`, nie `includeSubDomains` oder `preload`. Nur angeboten, wenn der letzte Scan die Live-Antwort jeder Wurzel über `https://` abgerufen hat.	die Live-Antwort muss den Header enthalten; „konfiguriert, aber nicht beobachtet“ ist ausstehend, nie behoben	ja
`headers.https_context`	AutoConfirm	Schaltet „SSL verwenden“ (`tl_page.useSSL`) für Wurzeln ein, die noch `http://`-URLs erzeugen – nur mit Nachweis, dass `https://` funktioniert, und nie aus einem Klartext-HTTP-Backend. Zertifikate, Weiterleitungen und Webserver-TLS werden angeleitet, nicht behauptet.	Prüfung wiederholt	ja
`headers.conflicts`	Assisted	Je Konflikt: Header, beobachtete Werte, Sollwert, wahrscheinliche Quelle (CDN / Webserver) und die genaue Maßnahme. Eine andere Schicht besitzt den Wert; die Anwendung kann sich dagegen nicht sicher durchsetzen.	nächstes Audit	–
`csp.configuration`	AutoConfirm	Eine erzwungene Richtlinie je Wurzel aus der eigenen Architektur der Suite (Basis oder gespeicherte Konfiguration der Wurzel). Eine fremde Richtlinie wird nie ersetzt.	Prüfung wiederholt	ja
`csp.policy_quality`	AutoConfirm	Wendet die eigene kompilierte Richtlinie einer verwalteten Wurzel erneut an, wenn die gespeicherte Richtlinie abgewichen ist (Wildcard, `unsafe-eval`, Reporting an). Listet genau, welche Quellen verschwinden. Eine Schwäche in der Konfiguration selbst oder eine nicht verwaltete Richtlinie bleibt manuell.	Prüfung wiederholt	genauer vorheriger Zustand
`csp.inline_styles`	AutoConfirm	Ersetzt die alte pauschale Option `style-src 'unsafe-inline'` durch das eingegrenzte `style-src-attr` – nur, wo das installierte Contao es akzeptiert. `script-src` wird nie angefasst.	Prüfung wiederholt	genauer vorheriger Zustand
`authentication.backend_2fa`	Assisted	Nennt jedes betroffene Konto mit Direktlink zu seinem Contao-Datensatz. Die Suite richtet nie jemanden ein und erzeugt kein Geheimnis.	Contao meldet 2FA aktiv	–
`users.admin_hygiene`	Assisted	Direktlink zu jedem markierten Konto. Wer welches Privileg hält, ist eine menschliche Entscheidung.	nächstes Audit	–
`users.privileged_groups`	Assisted	Direktlink zu jeder markierten Gruppe. Es wird nie eine Berechtigung für Sie entfernt.	nächstes Audit	–
`authentication.request_token`	Manual	Der CSRF-Schutz lässt sich von innerhalb der Anwendung nicht reparieren, wenn der Token-Manager im Container fehlt.	nächstes Audit	–
`files.sensitive_exposure`	AutoConfirm	Verschiebt exponierte Dateien in den nicht öffentlichen Quarantänebereich. Löschen ist eine eigene, ausdrücklich bestätigte Aktion je Datei.	ursprünglicher Pfad weg, Scan wiederholt	ja (Wiederherstellen)
`files.suspicious`	AutoConfirm	Verschiebt verdächtige oder getarnte Uploads in die Quarantäne, ohne sie zu öffnen oder auszuführen. Löschen bleibt eine eigene ausdrückliche Aktion.	ursprünglicher Pfad weg, Scan wiederholt	ja (Wiederherstellen)
`files.permissions`	AutoConfirm	Entfernt das Schreibrecht für alle (nur dieses Bit) bei genau den Dateien, die der Scan genannt hat – nie einen Baum, nie einen Symlink.	jeder Modus neu gelesen, Prüfung wiederholt	ja (vorherige Modi)
`files.integrity`	Assisted	Listet, was sich geändert hat, lässt Sie eine hinzugekommene Datei in Quarantäne verschieben und sagt, dass das Aktualisieren der Baseline eine eigene Entscheidung ist. Es gibt keine vertrauenswürdige Kopie zum Wiederherstellen, und das Akzeptieren einer Änderung würde einen möglichen Einbruch verbergen – daher nie eine „Behebung“.	nächstes Audit	–
`extensions.known_vulnerabilities`	AutoConfirm	Ein eingegrenztes `composer update <verwundbare Pakete>` mit `--no-scripts --no-plugins`: zuerst ein Probelauf (er darf nichts entfernen, nichts herabstufen, kein fremdes Contao-Kernpaket berühren und muss in einem kleinen Paketbudget bleiben), `composer.json` / `composer.lock` gesichert. Nie ein uneingeschränktes `composer update`.	ein frisches `composer audit --locked` findet keinen Hinweis	Dateien wiederhergestellt + `composer install`
`extensions.abandoned`	Assisted	Direkt oder transitiv, der von Composer genannte Ersatz und die genauen Befehle. Ein Paket zu ersetzen ist eine Kompatibilitätsentscheidung.	nächstes Audit	–
`extensions.composer_integrity`	AutoConfirm	`composer install --no-scripts --no-plugins` – installiert genau das, was `composer.lock` festschreibt, und ermittelt nie neue Versionen. Eine fehlende Lock-Datei oder eine ungültige `composer.json` bleibt bei einem Menschen.	Integritätsanalyse wiederholt	–
`server.app_debug`	AutoConfirm	Schreibt `APP_DEBUG=0` in die `.env.local` des Projekts (andere Zeilen bleiben erhalten).	ausstehend, bis der nächste Start es beweist	ja
`server.php_version`	Manual	Ein PHP-Upgrade ändert die gesamte Plattform.	–	–
`system.php_runtime`	AutoConfirm	Schreibt `display_errors` / `display_startup_errors` in die `.user.ini` im Document-Root (projektlokal, andere Direktiven bleiben erhalten, nie eine globale `php.ini`) und entfernt den PHP-Header `X-Powered-By`. `allow_url_include` und `expose_php` selbst sind serverseitig und bleiben angeleitet.	Datei zurückgelesen; ausstehend, weil PHP die `.user.ini` nur alle `user_ini.cache_ttl` Sekunden neu liest	ja
`system.session_cookies`	AutoConfirm	Schreibt die Session-Cookie-Flags in die `.user.ini` (`Secure` nur, wenn Sie über HTTPS arbeiten, kann Sie also nie aussperren).	Datei zurückgelesen; ausstehend bis zum nächsten Scan	ja
`system.trusted_proxies`	Assisted	Die genauen derzeit vertrauenswürdigen Bereiche und eine Beispielkonfiguration. Welchen Adressen vertraut wird, hängt vom Netzwerk vor der Website ab.	nächstes Audit	–
`contao.version`	Manual	Ein Contao-Upgrade muss von einem Menschen geplant, getestet und durchgeführt werden.	–	–
`users.inventory`	None	informativ	–	–

Abdeckung nach Klasse: 27 Prüfungen – 1 AutoSafe, 14 AutoConfirm, 7 Assisted, 4 Manual, 1 None. Ein Test zählt jede registrierte Prüfung auf und schlägt fehl, wenn eine ohne ausdrückliche Behebungsentscheidung hinzukommt.

Wie eine Behebung abläuft

Einzel-Fix – eine Schaltfläche je offener Feststellung, benannt nach dem, was sie wirklich tut (Header korrigieren, CSP anwenden, Datei sichern, Rechte korrigieren, Paket aktualisieren, Paket auflösen, 2FA einrichten, Berechtigungen prüfen, Anleitung ansehen, …). Die Detailansicht zeigt das erkannte Problem, warum es wichtig ist, was sich ändert, die Auswirkung auf die Kompatibilität, ob ein Rollback möglich ist und wie es verifiziert wird.
Bereichs-„Alle beheben“ – oben in jedem Bereich, der Feststellungen besitzt, vom selben Koordinator wie alles andere gesteuert. Es enthält die sicheren und (nach einer Bestätigung) die bestätigungspflichtigen Behebungen und führt „Prüfung erforderlich“ und manuelle Punkte getrennt.
Globales „Alle beheben“ auf dem Dashboard – ein Dialog mit vier Gruppen: automatisch behoben, nach Ihrer Bestätigung hier behoben, Prüfung erforderlich und manueller Eingriff erforderlich. Eine Bestätigung autorisiert den ganzen Lauf – nie ein Dialog je Feststellung. Die Zwei-Faktor-Authentifizierung ist immer ausgenommen.
Jede Behebung durchläuft Vorschau → Anwenden → Verifizieren → erneuter Scan → Auflösen. Ein Schreibvorgang ist nie ein Beweis. Ein Handler beweist die Behebung entweder selbst (Live-Antwort neu abrufen, Dateien zurücklesen, ein frisches composer audit) oder die Prüfung hinter der Feststellung wird wiederholt. Wird eine Änderung korrekt geschrieben und zurückgelesen, wirkt aber erst später (.user.ini, .env.local), wechselt die Feststellung auf „Behebung ausstehend“ – sie ist nicht behoben –, und der nächste Scan löst sie auf oder öffnet sie nach 24 Stunden wieder, falls die Wirkung nie eintrat.
Fehlerbehandlung – eine fehlgeschlagene oder nicht verifizierte Behebung hält die Feststellung offen, behält einen kurzen Fehlerkontext, erzeugt ein Sicherheitsereignis und bricht die unabhängigen Behebungen eines Sammellaufs nie ab. Weder Stack-Trace noch Geheimnis erreichen die Oberfläche.
Rollback wird nur angeboten, wo die Suite den vorherigen Zustand besitzt (CSP, Header-Konfiguration, Suite-Einstellungen, projektlokale PHP-Konfiguration, .env.local, Quarantäne-Dateien, Dateimodi, Composer-Dateien). Der Verlauf steht in tl_secsuite_remediation; der Schnappschuss enthält nie Geheimnisse.
Nie eine Behebung: Ignorieren, Risiko akzeptieren, Schweregrad ändern, eine Prüfung deaktivieren, die Integritäts-Baseline automatisch aktualisieren, eine Warnung unterdrücken oder eine Feststellung von Hand als behoben markieren ändern nur den Status – sie ändern nicht den zugrunde liegenden Zustand und zählen nie als Behebung.
Jede Meldung, Vorschau, Warnung, Bestätigung, Anleitung und jeder Fehlertext ist übersetzt (EN/DE); kein sichtbarer Text ist in JavaScript fest hinterlegt.

Was bei einem Menschen bleibt – und warum

2FA-Einrichtung – jeder Kontoinhaber muss sich selbst einrichten; die Suite erzeugt nie ein Geheimnis.
Administratorrechte und Gruppenberechtigungen – eine Entscheidung über Menschen, keine Konfiguration.
Änderungen der Dateiintegrität – von Natur aus mehrdeutig; die Baseline hält Hashes, keine Kopien.
Aufgegebene Pakete und Composer-Migrationen, deren Kompatibilität die Suite nicht beweisen kann.
Externe TLS-/Webserver-/CDN-Konfiguration – Zertifikate, Weiterleitungen und Header-Regeln außerhalb der Anwendung; die Suite zeigt genau, was zu ändern ist.
PHP- und Contao-Upgrades sowie ein fehlender CSRF-Token-Manager.

Kommandozeilenbefehle

# Audit-Prüfungen ausführen und das Ergebnis aufzeichnen (nur lesend)
vendor/bin/contao-console security-suite:scan
#   Exit-Code 0 = sauber, 1 = mittlere Findings oder Prüffehler,
#   2 = hohe Findings, 3 = kritische Findings, 4 = Scan selbst fehlgeschlagen

# Die konfigurierten Aufbewahrungsfenster auf Ereignisse, Scans, aggregierten
# Schutzstatus und aufgelöste Findings anwenden
vendor/bin/contao-console security-suite:purge-events
vendor/bin/contao-console security-suite:purge-events --days 30
vendor/bin/contao-console security-suite:purge-events --dry-run

security-suite:scan braucht eine gültige signierte Free- oder Pro-Lizenz (sonst Exit-Code 5); security-suite:purge-events ist Datenpflege und läuft unabhängig davon. Verändernde Aktionen (Behebung, Konfiguration, Export) gibt es nicht als CLI-Pfad.

Geplante Aufgaben (Cron)

Cron-Job	Intervall	Wirkung
Aufbewahrung	täglich	Wendet die konfigurierten Aufbewahrungsfenster an; entfernt nur Zeilen, die älter als die (begrenzten) Fenster sind.
Geplanter Scan	jedes von Contao unterstützte Intervall	Führt nur dann einen Scan aus, wenn die Einstellungen geplante Scans aktivieren und die konfigurierte Frequenz zum ausgelösten Intervall passt.

Beide setzen einen laufenden Contao-Cron voraus (contao:cron). Wird der Cron auf dem Server nicht ausgelöst, geschieht nichts – und der Einstellungen-Bereich sagt das offen und verweist auf den direkten Befehl security-suite:scan.

Laufzeitverzeichnisse

Pfad	Inhalt
`var/contao_security_suite/`	Private Laufzeitdaten der Suite, darunter die Lizenzdaten. Liegt außerhalb des öffentlichen Web-Roots. Muss beschreibbar sein.
`public/bundles/vtinnovationscontaosecuritysuite/`	Bei der Paketinstallation kopierte Backend-Assets (CSS/JS).
`var/contao_security_suite/quarantine/`	Von „Datei sichern“ / der Dateibehebung aus dem Web-Root verschobene Dateien, je mit JSON-Manifest. Nie per Web erreichbar.
`var/contao_security_suite/backups/`	Sicherungen von `composer.json` / `composer.lock` vor einem eingegrenzten Paket-Update (für den Rollback).
`public/.user.ini`, `.env.local`	Nur von der System-Behebung geschrieben (markierter Block / eine Variable, übriger Inhalt bleibt erhalten; der vorherige Inhalt ist der Rollback-Schnappschuss).
Datenbank	20 Tabellen mit dem Präfix `tl_secsuite_` plus ein Feld in `tl_settings`. Das Schema wird von `contao:migrate` verwaltet; die tägliche Aufbewahrung bereinigt auch alte Request-Fenster, Benachrichtigungs-Cooldowns, externe Aktionen und Threat-Intelligence-Caches.

Datenbanktabellen

tl_secsuite_scan, tl_secsuite_finding, tl_secsuite_finding_history, tl_secsuite_event, tl_secsuite_remediation, tl_secsuite_snapshot, tl_secsuite_csp_config, tl_secsuite_csp_backup, tl_secsuite_header_config, tl_secsuite_file_baseline, tl_secsuite_setting, tl_secsuite_setting_log, tl_secsuite_ip_block, tl_secsuite_source, tl_secsuite_request_window, tl_secsuite_notification, tl_secsuite_session, tl_secsuite_external_block, tl_secsuite_intelligence und tl_secsuite_lockdown (Zustand des Aktiven Schutzes, der Sitzungen, der Edge-Durchsetzung und der Intelligence). Alle sind reine Speicher-Tabellen (keine BE_MOD-Tabellen, keine Bearbeitung von Hand). Abgelaufene/alte Betriebszeilen werden täglich bereinigt; Einstellungen, Schnappschüsse und CSP-Backups bleiben Konfigurations- bzw. Rollback-Zustand.

Externe Kommunikation

Die lokale Analyse benötigt keine fremde externe Abhängigkeit. Optionale externe Kommunikation ist standardmäßig deaktiviert und findet nur in diesen klar abgegrenzten Fällen statt:

Lizenzaktivierung und „Lizenz aktualisieren" – definierte Operationen, ausgelöst durch einen Administrator im Contao-Einstellungen-Bereich, gerichtet an den vertrauenswürdigen V‑T.ONE-HTTPS-Dienst. Der Browser kommuniziert nie direkt mit dem Anbieter.
Anbieter-initiierte Lizenzzustellung – ein einziger nicht im Backend liegender Endpunkt, über den der Anbieter ein vollständiges, signiertes Lizenzpaket zustellt. Die Zustellung ist authentifiziert und integritätsgeschützt.
composer audit – wird bei der Schwachstellenprüfung der Erweiterungen als Unterprozess aufgerufen und kann dabei den Composer-Advisory-Dienst kontaktieren. In den Einstellungen abschaltbar (advisory_network_enabled).
Live-Prüfungen (effektive HTTP-Header, öffentliche Erreichbarkeit sensibler Dateien) – senden HTTP-Anfragen an die eigene Website dieser Installation, nur während eines Scans oder einer manuellen Aktion. Die Ergebnisse werden in tl_secsuite_snapshot zwischengespeichert.
Paketbehebung – ein vom Administrator bestätigtes „Paket aktualisieren“ / „Paket auflösen“ startet Composer als Unterprozess (composer update <Paket> / composer install, ohne Skripte, ohne Plugins), der die konfigurierten Composer-Repositories kontaktiert.

Protokollierung

Die Suite protokolliert über den eigenen Monolog-Kanal contao_security_suite (sofern Monolog verfügbar ist). In Ereignissen, im Behebungsverlauf und in Protokollen stehen keine Geheimnisse: Der Lizenzschlüssel wird nie zurückgegeben (nur seine letzten Zeichen werden angezeigt), Header-/CSP-Snapshots enthalten Konfigurationswerte, aber keine Zugangsdaten, und Einstellungswerte werden als kurze Zeichenketten geführt. IP-Adressen können über die Einstellung privacy_mask_ips maskiert werden; Berichte können Benutzernamen maskieren und IP-Adressen ausschließen.

Sicherheitsmodell

Verifizierte Kontrollen:

Zugriffssteuerung – jeder Bereich ist ein einzeln rechtlich geprüftes Contao-Backend-Modul.
Serverseitige Berechtigungsdurchsetzung – jede Pro-Fähigkeit wird an ihrer eigenen Grenze geprüft (Backend-Bereiche, verändernde Aktionen, Behebung, Befehlszeile und Hintergrundaufgaben).
Authentifizierte Anfragen – jede verändernde Aktion ist POST-only, im Backend-Scope, mit Contao-Request-Token; kein GET-Pfad verändert Zustand.
Restriktiv bei Fehlern – ein Lizenzproblem entlizenziert (kein Scan, keine Pro-Funktionen); es macht das Backend nie defekt und löscht nie Daten.
Private Ablage – der Lizenzdatensatz liegt unter var/, außerhalb des Web-Roots.
Integritäts- und Authentizitätsprüfung – ausgetauschte Lizenzdaten werden authentifiziert und integritätsgeschützt übertragen; ein nicht verifizierbares Paket wird verworfen und der installierte Zustand bleibt unverändert.
Sicheres Fehlverhalten – der CSP-Writer schreibt eine ungültige Policy nie; der tl_page-Schreibvorgang, das Backup und die Konfigurationsaktualisierung laufen in einer Transaktion; die Baseline wird von einem Scan nie überschrieben.
Geschwärzte Protokollierung – siehe oben.

Unterscheiden Sie:

Garantiertes Verhalten – durch Code festgelegt (z. B. „ein Scan ändert nichts", „POST + Token für jede Aktion", „ungültige CSP wird nie geschrieben").
Bedingtes Verhalten – hängt von der Umgebung ab (z. B. geplante Scans brauchen einen laufenden Contao-Cron; composer audit braucht ein ausführbares composer).
Best-effort – z. B. das Invalidieren des Seiten-Cache-Tags nach einer CSP-Änderung.
Bekannte Grenzen – siehe unten.

Die Suite trifft keine Aussage darüber, dass ein Lizenz- oder Sicherheitssystem nicht umgangen werden könne.

Deployment und Cache

Nach jeder Aktualisierung des Bundles:

vendor/bin/contao-console contao:migrate
vendor/bin/contao-console cache:clear

Über den Contao Manager werden beide Schritte automatisch ausgeführt. Ein separater Build-Schritt für die Backend-Assets ist nicht nötig; sie werden bei der Paketinstallation nach public/bundles/ kopiert.

Tests

composer test           # Unit- und Integrationssuite
composer test:unit
composer test:integration
composer lint            # PHP-Syntax, Konfigurations- und Twig-Prüfungen
composer security        # composer validate --strict und composer audit

Die Testsuiten sind in phpunit.xml.dist definiert (unit und integration).

php tools/remediation-coverage.php gibt die Behebungsklassifizierung jeder registrierten Prüfung mit dem sie stützenden Handler bzw. der Anleitung aus (gesamt / AUTO_SAFE / AUTO_CONFIRM / ASSISTED / MANUAL / NONE); tests/Remediation/RemediationCoverageTest.php schlägt fehl, wenn eine Prüfung ohne ausdrückliche Behebungsentscheidung hinzukommt oder ein Behebungssatz in EN oder DE fehlt.

Fehlerbehebung

Symptom	Ursache und Abhilfe
„Security Suite" erscheint nicht in der Navigation	Migration ausführen und Cache leeren; sicherstellen, dass der Benutzer das Recht am Modul `security_suite_dashboard` hat.
Alle Bereiche außer Dashboard sind gesperrt	Die Installation ist nicht lizenziert oder läuft als Free. Eine gültige Lizenz unter Einstellungen → „V‑T.ONE Licence management" aktivieren.
„Für diese Installation ist keine Domain konfiguriert"	Auf der Startseite (Root-Seite) in der Seitenstruktur eine Domain eintragen und die Lizenz erneut aktivieren.
Der Erweiterungen-Bereich meldet „Advisory-Daten nicht verfügbar"	`composer` ist auf dem Server nicht ausführbar oder der Aufruf konnte nicht abgeschlossen werden. Das ist ausdrücklich nicht dasselbe wie „keine Schwachstellen".
Geplante Scans laufen nicht	Es ist kein Contao-Cron eingerichtet. `contao:cron` per System-Cron einrichten oder `security-suite:scan` direkt aufrufen.
„Die Lizenz wurde verifiziert, konnte aber nicht gespeichert werden"	`var/contao_security_suite/` ist nicht beschreibbar.
Der CSP-/Header-Bereich zeigt keine Website-Roots	Es ist keine Root-Seite mit Domain konfiguriert.

Tatsächliche bekannte Einschränkungen

Die SSL/TLS-Domäne nutzt eine begrenzte HTTPS-Zertifikatsprüfung. Sie kann Erreichbarkeit, Ablauf und Hostnamenabweichungen melden, ist aber kein vollständiger TLS-Scanner, prüft keine Cipher-Suiten und behauptet keinen SSL-Labs-Score.
contao.version und server.php_version melden die installierten Versionen, vergleichen sie aber noch nicht gegen eine gepflegte Advisory-Quelle; die Zusammenfassung sagt das offen.
headers.https_context wertet das Anfrageschema und das „SSL verwenden“-Flag je Root aus; es prüft weder Zertifikate noch Weiterleitungen. Das sind Angelegenheiten von Webserver / CDN, die die Suite nicht ändern kann – die Anleitung sagt das.
expose_php und allow_url_include (PHP_INI_SYSTEM) lassen sich aus der Anwendung heraus nicht ändern. Die Suite entfernt den X-Powered-By-Header und leitet den Rest an; sie behauptet keinen Erfolg ohne Laufzeitbestätigung.
Die .user.ini wird nur unter FPM / FastCGI / CGI und nur alle user_ini.cache_ttl Sekunden gelesen; Behebungen von PHP-Laufzeit und Session-Cookies sind daher bis zum nächsten Scan „Behebung ausstehend“. Eine echte Server-Umgebungsvariable überschreibt .env.local.
Die Paketbehebung braucht ein ausführbares composer und ein beschreibbares vendor/; ohne beides wird der genaue Composer-Befehl gezeigt. Die Nacharbeiten von Contao (Cache-Aufwärmen, Datenbankprüfung) führt die Suite nicht aus.
Bewusst nie automatisiert: 2FA-Einrichtung, Administratorrechte, Akzeptieren der Integritäts-Baseline, Ersatz aufgegebener Pakete, PHP-/Contao-Upgrades, TLS- und Webserver-Konfiguration.
Geplante Scans hängen von einem laufenden Contao-Cron ab.
Anwendungsschutz kann eine statische Datei nicht abfangen, die nginx/Apache vor PHP ausliefert; dafür sind Server-Hinweise und die Files-Findings vorgesehen.
Cloudflare und Threat Intelligence sind optional, ergänzend und ausfallsicher. Externe Aufrufe werden eingeplant oder ausdrücklich ausgelöst; der lokale Schutz wartet nicht darauf.

Lizenz und Urheberrecht

Diese Software ist kein Open-Source-Produkt. Die Nutzung des Pro-Funktionsumfangs setzt eine gültige, an die Installationsdomäne gebundene Lizenz voraus.

Weiterführende Dokumentation

README.en.md – englische Fassung dieses Dokuments.
Documentation/Sicherheitspruefungen.md – vollständige Referenz der 27 Sicherheitsprüfungen.
Documentation/Lizenzierung.md – Editionen, Lizenzzustände, Aktivierung und Berechtigungsmatrix.
Documentation/Konfiguration.md – alle Einstellungen, Aufbewahrung, geplante Scans, CSP- und Header-Arbeitsablauf.
Documentation/Aktiver-Schutz-Stage2.md, Stage3, Stage4 – Aktiver Schutz im Detail; Abnahmeprotokolle: Abnahmetest, Stage-4-Abnahmetest.
Documentation/Release-Bereitschaft.md – Release-Audit und Lizenzmatrix (PASS / TEILWEISE / NICHT LIVE GETESTET).

vtinnovations / contao-security-suite

Package info

Security

Statistics