Web Hosting prüfen, Lücken schließen, erneut prüfen: Ein Vorher-Nachher-Beispiel mit dem Security Check

Kategorien: Security

„Bei uns ist noch nie etwas passiert“ ist kein Sicherheitskonzept. Die meisten Angriffe auf Websites nutzen keine exotischen Tricks, sondern bekannte, vermeidbare Schwachstellen: veraltete Software, fehlende Schutzeinstellungen beim Hosting, offene Standardrouten. Das Tückische daran: Man sieht sie nicht, solange man nicht gezielt nachschaut.

Dieser Beitrag zeigt den ganzen Kreislauf an einem Beispiel: Ein Webhosting mit WordPress-Website wird geprüft, die Befunde werden Schritt für Schritt behoben, anschließend wird erneut geprüft. Dabei geht es nicht um Theorie, sondern um den praktischen Ablauf, den Sie auf Ihre eigene Website übertragen können.

Hinweis zum Beispiel: Die geschilderte Website ist ein Szenario. Die Ausgangsbefunde sind dem u.g. Security Checks nachempfunden und typisch für viele Websites auf Standard-Hosting. Alle Werte dienen der Veranschaulichung. Ihre eigenen Ergebnisse werden abweichen, und Sie sollten nur Websites prüfen, für die Sie verantwortlich sind oder eine Erlaubnis haben.

Das Wichtigste in Kürze

• Ein Vorher-Nachher-Vergleich macht Sicherheit messbar: Ohne Ausgangswert lässt sich kein Fortschritt belegen.
• Der Ablauf besteht aus fünf Schritten: prüfen, Bericht lesen und priorisieren, beheben, dokumentieren, erneut prüfen.
• Viele Befunde lassen sich in Minuten lösen, etwa DNS-Einträge und HTTP-Header. Andere brauchen den Hoster.
• Ein Backup vor jeder Änderung ist Pflicht, Änderungen erfolgen nacheinander und nicht alle auf einmal.
• Nach den Korrekturen bestätigt ein Re-Check, ob die Maßnahmen wirklich wirken.

Die Ausgangslage im Beispiel

Unser Beispielbetrieb, nennen wir ihn „Beispiel-Betrieb“, betreibt unter beispiel-betrieb.de eine WordPress-Website auf einem klassischen Shared-Hosting-Tarif. Die Seite wurde vor Jahren eingerichtet, ein Dienstleister hat sie gelegentlich gepflegt, zuletzt aber vor längerer Zeit. Es gibt ein Kontaktformular, einen Newsletter-Dienst und E-Mail-Postfächer beim selben Anbieter.

Eine Frage steht im Raum: Wie sicher ist das eigentlich, und was genau sollte zuerst angepackt werden?

Schritt 1: Die erste Prüfung

Für die Bestandsaufnahme verwenden wir den Website Security Check. Er prüft eine Website von außen, so wie es auch ein Angreifer tun würde, und fasst alles in einem Bericht zusammen.

Was geprüft wird

Für ein Webhosting sind besonders diese Bereiche aufschlussreich:

• Domain und DNS: SPF, DKIM, DMARC und weitere Einträge, die vor gefälschten E-Mails im Namen Ihrer Domain schützen
• Hosting und Infrastruktur: Provider, Mail-Server, CDN und Netzwerkzuordnung (ASN), einschließlich einer Sicherheitsanalyse des Mail-Providers
• SSL/TLS: Zertifikat, unterstützte Protokollversionen, Cipher-Suites und HSTS
• Web-Server-Antworten: Sicherheits-Header, aktive TRACE-Methode und verräterische Server-Banner
• CMS und Plugins: Erkennung von WordPress, TYPO3 und anderen Systemen sowie Abgleich mit bekannten Schwachstellen (CVE)
• JavaScript und Formulare: Prüfung auf XSS-Risiken und unsichere Formularverarbeitung
• Cookies und Speicher: Cookies, LocalStorage und SessionStorage auf sensible Inhalte
• IP-Reputation: Blacklist- und Abuse-Einträge, die auch dann auftreten können, wenn ein Nachbar auf demselben Server auffällig wird
• security.txt: Prüfung, ob ein Kontaktweg für Sicherheitsmeldungen nach RFC 9116 vorhanden ist

Der Scanner arbeitet regelbasiert. Künstliche Intelligenz kommt laut Anbieter nur für die verständliche Zusammenfassung einzelner Befunde zum Einsatz, die Diagnosen selbst stammen aus festen Prüfroutinen.

Ablauf und Aufwand

Der Ablauf ist bewusst einfach: URL eingeben, der Scan startet automatisch, am Ende kommt ein Link zum fertigen Bericht per E-Mail. Der Scan dauert in der Regel etwa 15 Minuten, arbeitet mit geringer Last und verändert nichts an Ihrer Website.

Ein Punkt verdient Aufmerksamkeit: Der Standard-Scan enthält einen leichtgewichtigen Portscan, um die Backend-Infrastruktur zu erfassen. Wer das nicht möchte, kann ihn bei der Bestellung abwählen und verliert dadurch nur die Prüfung der Backend-Software und offener Ports. Alle übrigen Bereiche bleiben unverändert.

Für den Vorher-Nachher-Vergleich bietet sich der Pro-Check an, denn er enthält Re-Checks innerhalb von 30 Tagen. Genau das brauchen wir in Schritt 5.

Schritt 2: Den Bericht lesen und priorisieren

Der Bericht beginnt mit einer Gesamtbewertung und sortiert die Befunde nach Kritikalität. Jeder Befund enthält eine verständliche Erklärung, die möglichen Folgen und konkrete Lösungsschritte. Bei Schwachstellen (CVE) gibt es zusätzlich eine Diagnose-Anleitung, mit der sich prüfen lässt, ob man tatsächlich betroffen ist.

Im Beispiel ergibt der erste Scan diese Ausgangsbewertung:

Bereich	Bewertung vorher
Gesamtrisiko	D
SSL/TLS	C+
HTTP-Header	F
DNS und E-Mail	B

Insgesamt meldet der Bericht 20 Befunde, davon 8 mit globaler Wirkung (Infrastruktur, Server, DNS) und 12 seitenspezifische. Die zehn wichtigsten im Überblick:

Bereich	Befund	Schweregrad
CMS	WordPress-Kern veraltet, bekannte Schwachstellen	Kritisch
CMS	Login-Route /wp-admin ohne Zusatzschutz erreichbar	Kritisch
JavaScript	Unsichere innerHTML-Zuweisung auf der Kontaktseite (XSS-Risiko)	Kritisch
DNS	Keine DMARC-Richtlinie	Hoch
Formular	Kontaktformular ohne CSRF-Schutz	Hoch
CMS	readme.html öffentlich erreichbar, verrät die Version	Hoch
CMS	Benutzerliste über die REST-API auslesbar	Hoch
HTTP-Header	Wichtige Sicherheits-Header fehlen	Hoch
TLS	Veraltete Protokollversionen noch aktiv	Hoch
Cookies	Sensible Werte in Cookies und LocalStorage	Hoch

Dazu kommen kleinere Punkte wie ein Server-Banner, das Software und Version verrät, und eine fehlende security.txt.

Falsch-positive Treffer vermeiden

Erkennt der Scanner eine Softwareversion falsch, kann das zu unnötigen Treffern führen. Im Bericht lässt sich die erkannte Version deshalb korrigieren oder ergänzen. Die Angabe wird gespeichert und beim nächsten Scan berücksichtigt. Das verbessert die Qualität der Schwachstellenanalyse spürbar.

Die Reihenfolge festlegen

Bei 20 Befunden hilft eine einfache Regel:

1. Zuerst ein vollständiges Backup von Dateien und Datenbank, bei Bedarf zusätzlich ein Test auf einer Staging-Kopie.
2. Dann die kritischen Befunde, weil sie am häufigsten ausgenutzt werden.
3. Danach die schnellen Erfolge: DNS-Einträge, HTTP-Header, Datei-Bereinigung. Sie bringen viel Wirkung bei wenig Aufwand.
4. Der Rest wird geplant, etwa Rollout von Zwei-Faktor-Anmeldung oder strengere Richtlinien.

Wer kann was beheben?

Nicht jeder Befund liegt in Ihrer Hand. Bei Shared Hosting entscheidet der Anbieter über Serverdetails:

Befund	Selbst lösbar?	Wo
WordPress, Plugins, Themes aktualisieren	Ja	WordPress-Backend
PHP-Version anheben	Meist ja	Kundenmenü des Hosters
DNS-Einträge (SPF, DMARC, DKIM)	Ja	DNS-Verwaltung beim Hoster oder Registrar
HTTP-Header, Weiterleitung auf HTTPS	Meist ja	.htaccess oder Kundenmenü
TLS-Protokollversionen	Selten	Support des Hosters
Server-Banner, TRACE-Methode	Selten	Support des Hosters
Offene Ports, geteilte IP-Reputation	Nein	Support des Hosters
Formular- und JavaScript-Fehler	Ja	Theme, Plugin oder Entwickler

Schritt 3: Die Probleme beheben

Gehen wir die wichtigsten Befunde der Reihe nach durch. Die Beispiele verwenden beispiel-betrieb.de als Platzhalter. Wichtig: Testen Sie jede Änderung und nehmen Sie immer nur eine nach der anderen vor.

Software aktualisieren

Veraltete Software ist der häufigste Einstiegspunkt für Angriffe. Das gilt für den WordPress-Kern ebenso wie für Plugins, Themes und die PHP-Version.

1. Vollständiges Backup erstellen.
2. WordPress-Kern, Plugins und Theme im Backend aktualisieren (Dashboard, Aktualisierungen).
3. Nicht mehr benötigte oder nicht mehr gepflegte Plugins entfernen, nicht nur deaktivieren.
4. Im Kundenmenü des Hosters eine aktuell unterstützte PHP-Version auswählen und die Seite danach testen.

Mehr zur Bedeutung bekannter Lücken lesen Sie im Beitrag Angreifer brauchen Sekunden – Ihre Website braucht einen Plan.

E-Mail-Absicherung im DNS

Ohne DMARC können Dritte E-Mails in Ihrem Namen verschicken. Die Empfänger erkennen die Fälschung oft nicht. Die Lösung sind Einträge in der DNS-Verwaltung Ihrer Domain.

Zunächst DMARC im Beobachtungsmodus anlegen:

Name: _dmarc.beispiel-betrieb.de
Typ:  TXT
Wert: v=DMARC1; p=none; rua=mailto:dmarc@beispiel-betrieb.de

Wenn die Berichte zeigen, dass nur legitime Absender auftauchen, verschärfen Sie die Richtlinie schrittweise auf p=quarantine und später auf p=reject. Voraussetzung sind ein korrekter SPF-Eintrag und DKIM beim Mail-Anbieter:

Name: beispiel-betrieb.de
Typ:  TXT
Wert: v=spf1 include:spf.ihr-mailanbieter.de ~all

Es darf nur einen SPF-Eintrag pro Domain geben. Den passenden include-Wert nennt Ihr Mail-Anbieter.

HTTPS erzwingen und HTTP-Header setzen

Fehlende Sicherheits-Header sind einfach zu beheben und bringen viel. Bei Apache ergänzen Sie in der .htaccess, sofern das Modul mod_headers aktiv ist:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=86400"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>

Bei nginx tragen Sie die Zeilen im server-Block ein:

add_header Strict-Transport-Security "max-age=86400" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
server_tokens off;

Zwei Hinweise dazu:

• HSTS zunächst mit kurzer Laufzeit (hier ein Tag) setzen und erst nach erfolgreichem Test verlängern, etwa auf ein Jahr. Nehmen Sie includeSubDomains nur dazu, wenn alle Subdomains über HTTPS erreichbar sind.
• Content-Security-Policy ist wirksam, aber anspruchsvoll, weil WordPress und viele Plugins Inline-Code verwenden. Starten Sie mit Content-Security-Policy-Report-Only und werten Sie die Meldungen in der Browser-Konsole aus, bevor Sie die Richtlinie scharf stellen.

Server-Banner und TRACE

Zeigt der Server seine Software und Version an, erleichtert das gezielte Angriffe. Je nach Tarif lässt sich das selbst abstellen oder nicht:

ServerTokens Prod
ServerSignature Off
TraceEnable Off

Diese Apache-Einstellungen gehören in die Server-Konfiguration. Auf Shared Hosting wenden Sie sich dafür an den Support. In der php.ini verhindert expose_php = Off, dass PHP seine Version preisgibt.

TLS-Versionen

Die Protokolle TLS 1.0 und 1.1 gelten als veraltet. Aktiv sein sollten TLS 1.2 und 1.3. Das stellt in der Regel der Hoster ein. Fragen Sie im Support nach und achten Sie darauf, dass das Zertifikat automatisch erneuert wird.

WordPress-spezifische Härtung

Der CMS-Check prüft typische Angriffsflächen von WordPress. Im Beispiel waren vier davon relevant.

Login-Route absichern. Aktivieren Sie Zwei-Faktor-Authentifizierung für alle Konten mit Schreibrechten, begrenzen Sie Anmeldeversuche und beschränken Sie den Zugriff auf /wp-admin nach Möglichkeit auf bekannte IP-Adressen oder eine zusätzliche Passwortabfrage.

Versionsinformationen verbergen. Löschen Sie readme.html, oder sperren Sie die Datei, denn WordPress legt sie bei Updates neu an:

<Files readme.html>
Require all denied
</Files>

Benutzerliste schützen. Verhindern Sie, dass Besucher über die REST-API alle Benutzernamen abrufen können:

add_filter('rest_endpoints', function ($endpoints) {
    if (!is_user_logged_in()) {
        unset($endpoints['/wp/v2/users']);
        unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    }
    return $endpoints;
});

Prüfen Sie vorher, ob ein Plugin oder eine App diesen Endpunkt tatsächlich benötigt.

Unnötige Schnittstellen und Editoren schließen. Wird XML-RPC nicht gebraucht, lässt es sich sperren. Den Datei-Editor im Backend schalten Sie in der wp-config.php ab:

<Files xmlrpc.php>
Require all denied
</Files>

define('DISALLOW_FILE_EDIT', true);

Kontaktformular absichern

Ohne CSRF-Schutz lassen sich Formulare missbrauchen. Die meisten Formular-Plugins bieten diesen Schutz nach einem Update ab Werk. Bei selbst gebauten Formularen ergänzen Sie in WordPress ein Nonce:

<form method="post">
    <?php wp_nonce_field('kontakt_senden', 'kontakt_nonce'); ?>
    <label for="nachricht">Nachricht</label>
    <textarea id="nachricht" name="nachricht"></textarea>
    <button type="submit">Senden</button>
</form>

Und prüfen es beim Absenden serverseitig:

if (!isset($_POST['kontakt_nonce']) || !wp_verify_nonce($_POST['kontakt_nonce'], 'kontakt_senden')) {
    wp_die('Ungültige Anfrage.');
}

Ergänzend gehören Eingabevalidierung auf dem Server und ein Spam-Schutz (etwa ein unsichtbares Feld oder ein Zeitlimit) zu einem soliden Formular.

XSS-Risiko im JavaScript beseitigen

Wird Nutzereingabe ungeprüft per innerHTML in die Seite geschrieben, kann Schadcode eingeschleust werden. Schlecht:

ausgabe.innerHTML = eingabe;

Besser, wenn nur Text angezeigt werden soll:

ausgabe.textContent = eingabe;

Muss echtes HTML ausgegeben werden, bereinigen Sie es vorher mit einer geprüften Bibliothek wie DOMPurify und validieren die Eingabe zusätzlich auf dem Server.

Cookies und Speicher bereinigen

Session-Tokens oder E-Mail-Adressen gehören nicht in den LocalStorage, weil jedes eingebundene Skript sie auslesen kann. Sitzungsdaten setzen Sie besser als Cookie mit Schutzattributen:

setcookie('sitzung', $wert, [
    'expires' => 0,
    'path' => '/',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);

Kontaktweg für Sicherheitsmeldungen

Eine security.txt zeigt Sicherheitsforschern, wohin sie eine entdeckte Lücke melden können. Legen Sie die Datei unter /.well-known/security.txt ab:

Contact: mailto:sicherheit@beispiel-betrieb.de
Expires: 2027-09-30T23:59:59.000Z
Preferred-Languages: de, en
Canonical: https://www.beispiel-betrieb.de/.well-known/security.txt

Contact und Expires sind Pflichtfelder nach RFC 9116. Das Ablaufdatum sollte nicht mehr als ein Jahr in der Zukunft liegen und regelmäßig erneuert werden. Fehlt die Datei, liefert der Bericht des Security Checks eine fertige Vorlage.

Schritt 4: Fortschritt dokumentieren

Gerade wenn mehrere Personen beteiligt sind, etwa Geschäftsführung, Agentur und Hoster, ist Übersicht wichtig. Im Bericht des Security Checks lässt sich jeder Befund direkt mit einem Status versehen:

• Erledigt: Die Maßnahme wurde umgesetzt
• Nicht relevant: Der Befund trifft auf diesen Fall nicht zu
• Zurückgestellt: Wird später bearbeitet
• Ignoriert: Bewusst ausgeblendet, etwa bei einer bekannten, akzeptierten Einschränkung

Zu jedem Status können Sie einen Kommentar hinterlegen, zum Beispiel eine Ticketnummer, eine Begründung oder den Namen des Verantwortlichen. Die Angaben sind für alle Bearbeiter des Berichts sichtbar, sodass jeder auf demselben Stand arbeitet.

Aus den bearbeiteten Befunden lässt sich zusätzlich ein Abschlussbericht als Management Summary erstellen. Er zeigt, was erledigt und was noch offen ist, bewertet das verbleibende Restrisiko und lässt sich als PDF exportieren. Das ist ein brauchbarer Nachweis gegenüber Auftraggebern, Datenschutzbeauftragten oder Revisoren.

Schritt 5: Erneut prüfen

Erst der Re-Check zeigt, ob die Maßnahmen wirklich wirken. Das ist der Moment, in dem sich Mühe und Ergebnis vergleichen lassen. Ein gesetzter Header kann falsch ausgeliefert werden, ein Update ein anderes Problem öffnen, ein DNS-Eintrag noch nicht übernommen sein.

Warten Sie nach DNS-Änderungen etwas ab, bis die Einträge weltweit verbreitet sind, und leeren Sie bei Bedarf den Cache der Website. Starten Sie den Re-Check dann innerhalb des Zeitfensters von 30 Tagen, das der Pro-Check abdeckt.

Im Beispiel sieht das Ergebnis so aus:

Bereich	Vorher	Nachher
Gesamtrisiko	D	B
SSL/TLS	C+	A
HTTP-Header	F	B
DNS und E-Mail	B	A

Und der Status der 20 Befunde in der Befundverwaltung:

Status	Anzahl
Erledigt	14
Nicht relevant	2
Zurückgestellt	3
Bewusst ignoriert	1

Die drei zurückgestellten Punkte sind typisch: die scharf gestellte Content-Security-Policy, die erst ausgiebig getestet werden muss, ein Hosting-Thema, das der Anbieter umsetzen muss, und die Einführung der Zwei-Faktor-Anmeldung für alle Redakteure. Das ist in Ordnung, solange sie dokumentiert sind und einen Termin haben. Das Restrisiko ist deutlich gesunken, aber nicht null. Und auch nach dem Re-Check bleibt Sicherheit ein laufender Prozess.

Was Sie aus dem Beispiel mitnehmen können

1. Messen vor Handeln. Ohne Ausgangswert bleibt jede Verbesserung eine Behauptung.
2. Reihenfolge schlägt Perfektion. Kritische Befunde und schnelle Erfolge zuerst bringen den größten Gewinn.
3. Backup ist keine Kür. Jede Änderung am Live-System braucht einen Rückweg.
4. Der Hoster gehört dazu. Viele Punkte lassen sich nur gemeinsam mit dem Anbieter lösen. Wer die Befunde mit Erklärung ans Support-Ticket hängt, kommt schneller zum Ziel.
5. Dokumentieren zahlt sich aus. Wer Status und Kommentare pflegt, kann später belegen, was wann gemacht wurde.
6. Regelmäßig wiederholen. Neue Plugins, Updates und Konfigurationsänderungen bringen neue Risiken. Planen Sie die Prüfung als festen Termin ein, etwa halbjährlich und nach größeren Änderungen.

Häufige Fragen

Kann der Scan meine Website stören?

Nein, der Scan arbeitet mit geringer Last und ändert nichts an Ihrer Website. Er ist so ausgelegt, dass der laufende Betrieb nicht beeinträchtigt wird.

Muss ich nach jeder Änderung neu prüfen?

Nicht nach jeder einzelnen. Sinnvoller ist es, einen Block von Maßnahmen umzusetzen und dann zu prüfen. Bei riskanteren Änderungen, etwa an der Serverkonfiguration, kontrollieren Sie zwischendurch im Browser, ob die Seite noch einwandfrei funktioniert.

Ersetzt der Security Check einen Penetrationstest?

Nein. Er ist eine automatisierte Außenprüfung, die bekannte Schwachstellen und Fehlkonfigurationen zuverlässig findet. Ein Penetrationstest geht tiefer, prüft Logik und Berechtigungen und ist ein anderes Werkzeug mit anderem Aufwand.

Ist das auch ein DSGVO-Check?

Nein. Der Security Check enthält zwar einen Cookie-Scan und eine Basisprüfung der Datenschutzhinweise, ist aber auf Sicherheit ausgerichtet. Für eine vollständige datenschutzrechtliche Prüfung gibt es die DSGVO-Website-Checks.

Wird auch die Barrierefreiheit geprüft?

Optional ja. Der Barrierefreiheits-Check ist Teil des Pakets und prüft unter anderem Kontraste, Alternativtexte und Tastaturbedienung. Mehr dazu finden Sie auf der Seite zum Barrierefreiheits-Check. Automatische Tests decken allerdings nur einen Teil der Kriterien ab und ersetzen keine manuelle Prüfung.

Wann sollte ich Fachleute hinzuziehen?

Wenn Sie nicht sicher sind, wie ein Befund zu beheben ist, wenn die Änderung Server oder Datenbank betrifft oder wenn Sie bereits Anzeichen für eine Kompromittierung sehen, etwa unbekannte Administratoren, fremde Dateien oder Spam-Versand. Dann zählt schnelle, fachkundige Hilfe.

Fazit

Ein Vorher-Nachher-Vergleich macht aus einem diffusen Sicherheitsgefühl einen nachvollziehbaren Prozess: prüfen, die wichtigsten Befunde beheben, dokumentieren und erneut prüfen. Wer so vorgeht, schließt nicht nur Lücken, sondern kann auch zeigen, dass er es getan hat.

Wenn Sie wissen möchten, wo Ihre eigene Website steht, dann ist der Website Security Check ein guter Ausgangspunkt. Der Beispielbericht illustriert, wie ein Bericht aufgebaut ist.

Web Security kann Dank Automatisierung mit vernünftigem Aufwand geleistet werden - wichtiger denn je in Zeiten, wo Angreifer auch KI zum Finden von Schwachstellen einsetzen.