Website-Sicherheit online prüfen

Die eigene Website lässt sich in etwa einer Stunde mit kostenlosen Werkzeugen selbst prüfen, in vier Bereichen. Erstens Zertifikat und Verschlüsselung: Der SSL Server Test von Qualys SSL Labs bewertet den Hostnamen, den du eingibst, und dessen Endpunkte, und sagt dir, ob das Zertifikat dort gültig und vertrauenswürdig ist. Jede weitere Adressvariante bekommt einen eigenen Durchlauf. Zweitens die Sicherheits-Kopfzeilen, also die Anweisungen, die dein Server jedem Browser mitschickt: Der HTTP Observatory von Mozilla prüft sie, startet bei 100 Punkten und zieht für jede fehlende Einstellung ab. Drittens veraltete Software und bekannte Schwachstellen: Sucuri SiteCheck erkennt von außen sichtbare veraltete Systeme und Sperrlisten-Einträge, bei WordPress kommt die Schwachstellendatenbank von WPScan dazu. Viertens die offen erreichbaren Verwaltungsbereiche, der Teil, den kein Werkzeug für dich erledigt: Du schaust in einem abgemeldeten Browserfenster selbst nach, was von außen erreichbar ist, obwohl es das nicht sein sollte. Vor allem anderen steht eine Grenze, die unter Fachleuten selbstverständlich ist: Geprüft wird die eigene Website oder eine, für die eine schriftliche Freigabe vorliegt, sonst keine. Und was diese Tests grundsätzlich nicht sehen, ist der ehrlichste Teil dieses Beitrags.

Bei mir macht diese Arbeit ein KI-Mitarbeiter, der nicht bei einer Note stehenbleibt, sondern zu jedem Fund einen Beleg, eine Einstufung nach Schweregrad und einen Reparaturvorschlag liefert. Dazu unten mehr. Wenn du ohnehin gerade an deiner Seite arbeitest, gehören die vier Prüfungen in denselben Arbeitsgang wie ein Umbau des Bestands, denn nach jedem Relaunch verschieben sich Zertifikate, Weiterleitungen und Kopfzeilen.

Die Grenze, die vor jedem Test steht

Ein Sicherheitstest richtet Anfragen an ein fremdes System, auch wenn er harmlos aussieht. Deshalb gilt unter Leuten, die das beruflich machen, eine einfache Regel: Getestet wird nur das eigene System oder eines, für das eine schriftliche Freigabe des Betreibers vorliegt. Darin stehen Datum, Umfang, erlaubte Methoden, Zeitfenster, ein Notfallkontakt und die Absprache, wie mit gefundenen Daten umgegangen wird. Dazu gehört auch, vorher zu klären, was der Hoster und die Plattformbedingungen erlauben.

Das Strafrecht ist dabei enger gefasst, als oft behauptet wird. § 202a StGB, das Ausspähen von Daten, verlangt Daten, die nicht für den Täter bestimmt und gegen unberechtigten Zugang besonders gesichert sind, und dass die Zugangssicherung überwunden wird; der Strafrahmen reicht bis zu drei Jahren Freiheitsstrafe oder Geldstrafe. § 202b StGB, das Abfangen von Daten, setzt eine nichtöffentliche Datenübermittlung voraus, aus der mit technischen Mitteln Daten verschafft werden, Strafrahmen bis zu zwei Jahren oder Geldstrafe. Der bloße Aufruf einer öffentlich angebotenen Seite oder eine Abfrage ihrer Kopfzeilen erfüllt diese Merkmale in aller Regel nicht. Aktive Prüfungen an fremden Systemen können trotzdem strafrechtlich, vertraglich und betrieblich heikel werden, und genau deshalb steht die Freigabe davor. Ich bin kein Anwalt, und das hier ist keine Rechtsberatung.

Praktisch heißt das: Die Freigabe liegt vor dem ersten Aufruf vor, nicht danach, und sie benennt genau das gemeinte System, denn eine Freigabe für die Hauptdomain deckt nicht automatisch die Testumgebung auf einer Nebenadresse. Liegt deine Seite bei einem Dienstleister, sagst du ihm vorher Bescheid. In meinem Betrieb beginnt kein Test ohne schriftliche Freigabe. Die vier Werkzeuge unten sehen ohnehin nur von außen, was jeder Besucher auch sieht.

Schritt 1: Zertifikat und Verschlüsselung

Der SSL Server Test von Qualys SSL Labs ist kostenlos und bekommt nur deine Adresse. Er probiert die unterstützten Protokolle und Verfahren durch und gibt eine Note aus. Standardmäßig landet das Ergebnis auf einer öffentlichen Liste, es gibt aber eine Option, das zu unterbinden. Die setze ich immer. Die Note speist sich aus drei Bereichen: Protokollunterstützung zu 30 Prozent, Schlüsselaustausch zu 30 Prozent, Verschlüsselungsstärke zu 40 Prozent. Null Punkte in einem Bereich ergeben sofort ein F.

Die Note gilt für den Hostnamen, den du eingegeben hast, und für sonst nichts. Ob www, die Root-Domain und weitere Namen alle abgedeckt sind und richtig weiterleiten, prüfst du deshalb einzeln: Trag jede Variante einmal in den Test ein und ruf sie zusätzlich selbst auf. Ein T oder M taucht oft nur bei einer von beiden auf. Klicke dann auf das Schloss-Symbol und sieh dir das Ablaufdatum an, dann weißt du, ob die automatische Erneuerung läuft; was sonst im Zertifikat steht und welche Fehlermeldungen zählen, ist eine eigene Anleitung. Und tippe deine Adresse bewusst mit http:// ein: Du musst ohne eigenes Zutun auf der verschlüsselten Fassung landen. Ein Fehler hier hat Vorrang, denn eine Zertifikatswarnung klickt fast niemand weg.

Schritt 2: Sicherheits-Kopfzeilen im Browser

Jede Antwort deines Servers enthält neben der Seite ein paar Zeilen Anweisungen an den Browser. Fehlen sie, funktioniert die Website trotzdem, aber der Browser hat weniger Rückhalt, wenn jemand fremde Inhalte unterzuschieben versucht. Den Überblick liefert der HTTP Observatory von Mozilla, seit 2016 im Einsatz und heute kostenlos als Teil der MDN-Dokumentation. Er startet bei 100 Punkten, zieht für jede fehlende oder schwache Einstellung ab und vergibt ab 90 Punkten in einer zweiten Runde Bonuspunkte, der Gesamtbereich reicht von 0 bis 145. Die Noten: A+ ab 100, A ab 90, B ab 70, C ab 50, D ab 30, unter 25 ein F. Die Scan-Historie einer Domain ist öffentlich einsehbar, wer gescannt hat, aber nicht.

Dasselbe siehst du direkt im Browser: Seite öffnen, F12 drücken, Reiter „Netzwerk", neu laden, obersten Eintrag anklicken, unter „Response Headers" mitlesen. Das ist der schnellste Weg zu prüfen, ob eine Änderung tatsächlich angekommen ist. Eine schlechte Note heißt dabei nicht, dass deine Seite angegriffen wird, sondern dass Schutzschichten fehlen, die im Ernstfall helfen. Und eine gute Note heißt nicht, dass deine Seite sicher ist, sondern dass diese sieben Punkte stimmen. Der gefährlichste Fund aus Schritt 4 würde hier gar nicht auftauchen.

Schritt 3: Veraltete Software und bekannte Schwachstellen

Der häufigste Weg in eine kleine Website führt nicht über einen raffinierten Angriff, sondern über eine Erweiterung, deren Lücke seit Monaten öffentlich dokumentiert und seit Monaten nicht eingespielt ist. Das BSI formuliert für Webanwendungen genau das als Kernforderung: ausreichendes Schwachstellen- beziehungsweise Patchmanagement und die eingesetzten Komponenten regelmäßig auf aktuelle Sicherheitslücken überprüfen. Kleinen Betrieben rät es, sich einen Überblick über die eingesetzten Programme zu verschaffen und Sicherheitsupdates so rasch wie möglich einzuspielen oder die automatische Update-Funktion zu nutzen. Dieselbe Kategorie steht in der Fassung 2025 der OWASP Top 10 als A03 Software Supply Chain Failures weit oben.

Von außen prüfst du das so:

1. Sucuri SiteCheck aufrufen. Der kostenlose Dienst durchsucht den ausgelieferten Quelltext nach Schadcode, prüft den Sperrlisten-Status bei Stellen wie Google und PhishTank und erkennt veraltete Systeme und anfällige Erweiterungen, soweit von außen sichtbar.
2. Bei WordPress zusätzlich WPScan. Hinter dem Dienst steht Automattic, die zugehörige Datenbank führt über 83.700 dokumentierte Lücken in Kern, Plugins und Themes. Für kleine Betriebe ist das kostenlose Jetpack Protect der einfachste Weg, weil es dieselbe Datenbank gegen die tatsächlich installierten Erweiterungen abgleicht. Der Datenbankzugriff per Schnittstelle ist für nichtkommerzielle Nutzung auf 25 Abfragen pro Tag begrenzt.
3. Den Sperrlisten-Status bei Google nachsehen. Im Google Transparency Report gibt es unter „Safe Browsing site status" eine Abfrage, ob deine Adresse als unsicher eingestuft ist. Das ist die Einstufung, die im Ernstfall Besucher vor deiner Seite warnt.
4. Die eigene Liste führen. Welche Erweiterungen sind installiert, welche hat seit über einem Jahr kein Update bekommen, welche brauchst du noch. Die wirksamste Maßnahme ist hier meistens das Löschen, nicht das Aktualisieren.

Sucuri sagt zu den Grenzen selbst etwas Nützliches: Ein Scanner von außen habe nur begrenzten Zugriff, Ergebnisse seien nicht garantiert, und er sehe ausschließlich das, was auf Browser-Ebene sichtbar ist, nichts auf Serverseite. Genau deshalb gibt es Schritt 4.

Schritt 4: Offen erreichbare Verwaltungsbereiche

Diesen Schritt macht kein Online-Checker für dich. Öffne ein privates Browserfenster, damit du nirgends angemeldet bist, und geh deine eigene Website durch wie ein fremder Besucher:

1. Steht ein Verwaltungszugang offen, der es nicht sollte? Viele Anmeldeseiten müssen öffentlich erreichbar sein, für Kunden wie für dich selbst, und ihre bloße Sichtbarkeit ist keine Lücke. Trenne deshalb zwei Fälle. Bei einer beabsichtigten Loginseite zählt, was dahinter steht: Zwei-Faktor-Anmeldung, starke und nirgends sonst benutzte Passwörter, eine Begrenzung der Fehlversuche, ein regelmäßiger Blick in die Anmeldeprotokolle und, wo der Betrieb es zulässt, eine Beschränkung auf bekannte Netze. Diese Maßnahmen zielen auf die realen Risiken: das automatisierte Durchprobieren von Zugangsdaten aus fremden Datenlecks, nie geänderte Auslieferungszugänge und Berechtigungen, die nach dem Anmelden nicht noch einmal geprüft werden. Der zweite Fall ist der ernstere: ein Zugang, von dem du gar nicht wusstest, dass er von außen erreichbar ist.
2. Werden Verzeichnisse als Liste angezeigt? Ruf einen Ordner ohne Dateinamen auf, etwa den mit deinen Bildern. Du solltest eine Fehlerseite sehen, keine Dateiliste.
3. Liegen Sicherungskopien im Web-Verzeichnis? Archive und Datenbank-Auszüge gehören nicht dorthin, wo sie jeder herunterladen kann, sondern in eine getrennte Sicherung.
4. Sind Konfigurations- oder Versionsverwaltungsdaten mit ausgeliefert worden? Das passiert vor allem, wenn eine Seite per Datei-Upload statt über einen Build-Vorgang veröffentlicht wird. Solche Dateien können sensible Informationen offenlegen, bis hin zu Zugangsdaten.
5. Kennst du alle deine eigenen Adressen? Eine vergessene Testfassung ist seltener gepflegt als die Hauptseite. Die verlässliche Quelle dafür ist dein eigenes Inventar: die DNS-Einträge deiner Domain, die Einträge zu deinen Zertifikaten in den Transparenzprotokollen und die Projekte in deinem Hosting- und Deployment-Konto. Eine Suche nach site:deine-domain.de ergänzt das schnell, liefert aber keine vollständige Liste, weil sie nur zeigt, was eine Suchmaschine indexiert hat.
6. Verrät deine robots.txt mehr, als sie soll? Sie ist eine Bitte an Suchmaschinen, kein Schutz. Wer dort Verwaltungspfade auflistet, veröffentlicht ein Inhaltsverzeichnis.

Warum dieser Schritt so viel Gewicht hat, zeigt die Rangliste der OWASP Top 10 in der Fassung 2025: Broken Access Control, also fehlende oder falsche Zugriffsbeschränkungen, steht auf Platz 1, und Security Misconfiguration, also falsch eingestellte Systeme, ist von Platz 5 auf Platz 2 vorgerückt. Beides deckt ein automatischer Kopfzeilen-Test nicht ab.

Der Verbraucherzentrale-Check beantwortet eine andere Frage

Viele landen bei der Suche nach einer Sicherheitsprüfung beim Fakeshop-Finder der Verbraucherzentrale. Der ist gut und kostenlos, nur für eine andere Aufgabe: Er beantwortet die Käuferfrage, ob man in einem Shop bestellen kann, und schaut dafür auf Schreibweise der Adresse, Impressum, Zahlarten, Preise und Gütesiegel. Für deine eigene Seite zeigt die Ampel, ob sie auf Fremde vertrauenswürdig wirkt. Ob bei dir technisch etwas offen steht, beantwortet sie nicht.

Was die Ergebnisse bedeuten

Nach einer Stunde hast du eine Ausgangsaufnahme: drei Noten aus den Werkzeugen und eine eigene Liste der Stellen, die von außen erreichbar sind. Das ist der Stand, gegen den du jeden späteren Durchgang vergleichst. Jetzt geht es darum, die Funde nicht zu verwechseln.

Die Spalte „Erste Einordnung" ist genau das: eine Triage, keine Bewertung nach Standard. Für die gibt es das Common Vulnerability Scoring System, gepflegt von einer Arbeitsgruppe bei FIRST.Org, aktuell in Version 4.0 aus dem November 2023. Es erfasst die wesentlichen technischen Eigenschaften einer Schwachstelle und übersetzt sie in eine Zahl zwischen 0 und 10 und diese in vier Stufen: 0,1 bis 3,9 niedrig, 4,0 bis 6,9 mittel, 7,0 bis 8,9 hoch, 9,0 bis 10,0 kritisch. Die Spezifikation sagt selbst, dass Dinge wie regulatorische Vorgaben, Zahl der betroffenen Kunden, Geldschaden oder Rufschaden außerhalb von CVSS liegen und erst in der Bewertung der jeweiligen Organisation dazukommen. Für dich heißt das: Sobald eine Schwachstelle bestätigt ist, hältst du den CVSS-Vektor fest und priorisierst danach zusätzlich nach Exposition, realer Ausnutzbarkeit, Wert der betroffenen Daten und bereits vorhandenen Schutzmaßnahmen. Eine sichtbare Verzeichnisliste kann danach harmlos sein, und eine einzelne verwertbare Komponente kann sofortiges Handeln verlangen.

Was ein Online-Test grundsätzlich nicht sieht

Das ist der Teil, den Anbieter kostenloser Checker selten betonen, und der wichtigste. Alle vier Schritte oben schauen von außen auf eine abgemeldete Website. Systematisch unsichtbar bleibt:

• Alles auf der Serverseite. Dateien, Rechte, laufende Prozesse, hinterlegte Zugangsdaten. Sucuri schreibt das selbst so hin; wie du den Server selbst absicherst, ist eine eigene Anleitung.
• Alles hinter der Anmeldung. Kundenbereich, Bestellsystem, Verwaltungsoberfläche. Ein Test von außen kommt dort nie an.
• Ob Nutzer A die Daten von Nutzer B sehen kann. Die Kategorie auf Platz 1 der OWASP-Liste. Prüfbar nur, indem jemand sich mit zwei Konten anmeldet und von Hand versucht, die Grenze zu übertreten.
• Fehler in der Geschäftslogik. Ein Rabattcode, der sich beliebig oft einlösen lässt. Ein Formular, das eine Buchung ohne Bezahlung anlegt. Technisch korrekt, wirtschaftlich ein Schaden.
• Ob ein gemeldeter Fund überhaupt zutrifft. Ein Scanner erkennt ein Muster, nicht den Zusammenhang. Falsch-positive Treffer sind der Normalfall.
• Der Mensch. Wiederverwendete Passwörter, eine gefälschte Mail an die Buchhaltung, ein Zugang, der beim Ausscheiden nicht abgeschaltet wurde.
• Ob deine Sicherungskopien funktionieren. Das BSI nennt das Anlegen und regelmäßige Testen von Backups ausdrücklich als eine der ersten Schutzmaßnahmen. Testen heißt zurückspielen, nicht nur anlegen.

Dazu kommt eine weniger technische Grenze: Ein Checker liefert eine Liste, keine Reihenfolge. Er weiß nicht, über welche Unterseite deine Aufträge hereinkommen.

Wo eine gestufte Prüfung anfängt

Genau hier arbeitet bei mir Falk, mein KI-Mitarbeiter für Sicherheit. Er prüft in vier Stufen statt in einem Durchgang: von außen ohne jeden Zugang, dann als unauthentifizierter Besucher, und wo ich es freigebe, mit Zugang oder Einsicht in den Quellcode. Innerhalb einer Stufe folgt er fünf Phasen: Bestandsaufnahme der eingesetzten Technik ausschließlich aus öffentlich ausgelieferten Dateien statt aus Vermutungen, ein Angriffsflächenmodell entlang von Anmeldung und Sitzungsverwaltung, manuelle Tests auf typische Schwachstellenklassen, eine Werkzeugprüfung von Verschlüsselung und bekannten Mustern, und am Ende die Bewertung. Zu jedem Fund gehören ein Beleg, eine Einstufung nach dem CVSS-Standard und ein konkreter Reparaturvorschlag mit Priorität, nicht nur eine Auffälligkeit in einer Liste; wie so ein Audit von der Freigabe bis zur Nachprüfung abläuft, steht im eigenen Beitrag.

Drei Dinge daran sind der Unterschied zu einem Knopfdruck-Checker. Die Freigabe: Bevor auch nur eine einzige Anfrage an das Zielsystem geht, liegt eine schriftliche Freigabe für genau dieses System vor. Das Tempo: Der automatisierte Teil läuft bewusst gedrosselt mit vier parallelen Anfragen, begrenzt auf 20 pro Minute, ohne Last- oder Stresstests und ohne Ausprobieren von Zugangsdaten, weil ein Test den laufenden Betrieb nicht stören darf. Und die Abbruchkriterien: Instabilität, unerwartete Datenzugriffe oder Warnungen wegen zu vieler Anfragen stoppen den Test sofort. Der fertige Bericht durchläuft danach eine getrennte Prüf-Rolle, bevor ich ihn zu sehen bekomme. Dass jeder Auftrag seinen eigenen Rahmen und seine eigene Freigabe für genau das gemeinte Zielsystem bekommt, ist der Grund, warum diese Arbeit seriös ist: Jede Anwendung hat andere Zugänge, andere Daten und andere Grenzen. Wie Falk im Einzelnen vorgeht und wo ich ihn ausdrücklich bremse, steht auf Sicherheitslücken aufspüren: so arbeitet Falk.

Häufige Fragen

Was kostet eine Prüfung mit diesen Werkzeugen?

Nichts. Der SSL Server Test von Qualys SSL Labs, der HTTP Observatory von Mozilla, Sucuri SiteCheck, der Safe-Browsing-Status im Google Transparency Report und der Fakeshop-Finder der Verbraucherzentrale sind kostenfrei nutzbar, Stand September 2026. Bei WPScan ist der Datenbankzugriff per Schnittstelle für nichtkommerzielle Nutzung auf 25 Abfragen pro Tag begrenzt. Was dagegen eine beauftragte Prüfung kostet, hängt an sechs Treibern des Aufwands, nicht an einer Preisliste.

Darf ich die Website eines Kunden oder Wettbewerbers testen?

Nicht ohne schriftliche Freigabe des Betreibers, die vor dem Test vorliegt und das gemeinte System benennt. Die Strafvorschriften §§ 202a und 202b StGB greifen nicht bei jedem Aufruf einer öffentlichen Seite: Sie setzen besonders gesicherte Daten und die Überwindung der Zugangssicherung beziehungsweise eine nichtöffentliche Datenübermittlung voraus. Aktive Tests an fremden Systemen können trotzdem strafrechtlich, vertraglich und betrieblich heikel werden. Das ist keine Rechtsberatung, sondern die Regel, über die in meinem Betrieb nicht verhandelt wird.

Reicht die Note A+ als Nachweis, dass meine Website sicher ist?

Nein, und das ist der häufigste Denkfehler. Ein A+ im SSL-Test sagt, dass deine Verschlüsselung gut eingerichtet ist, und das für den getesteten Hostnamen. Über eine offene Verwaltungsoberfläche, eine seit einem Jahr nicht aktualisierte Erweiterung oder einen Fehler in der Zugriffsbeschränkung sagt er nichts. Noten bewerten je einen Ausschnitt, nicht das Ganze.

Wie oft sollte ich das wiederholen?

Leite den Rhythmus aus deiner Änderungsfrequenz und deinem Risiko ab: Eine Seite, an der monatlich gearbeitet wird, braucht häufiger einen Durchgang als eine, die seit zwei Jahren unverändert steht. Vierteljährlich ist für viele kleine Websites ein brauchbarer Ausgangswert. Zwei Dinge gehören trotzdem in eine automatische Überwachung statt in den Handbetrieb, weil sie zwischen zwei Durchgängen kippen: das Ablaufdatum deines Zertifikats und die Versionsstände deiner kritischen Erweiterungen. Und ein Durchgang gehört hinter jede Änderung an der Website.

Ich wollte den Datenschutz meiner Website prüfen, nicht die Technik.

Das ist eine andere Frage, auch wenn sie ähnlich klingt. Technisch geht es darum, ob etwas offen steht. Beim Datenschutz geht es darum, welche Daten du erhebst, auf welcher Grundlage und wen du darüber informierst. Für die Nutzung von KI-Werkzeugen habe ich das in Claude, Datenschutz und DSGVO aufgeschrieben.

Wie du weitermachst

Nimm dir eine Stunde und arbeite die vier Schritte in dieser Reihenfolge ab: SSL Server Test, HTTP Observatory, Sucuri SiteCheck, dann das private Browserfenster für die Verwaltungsbereiche. Schreib jedes Ergebnis mit Datum in eine Tabelle mit drei Spalten: Fund, Einordnung, erledigt am. Diese Tabelle ist das eigentliche Ergebnis der Stunde, denn beim nächsten Durchgang siehst du daran, was sich bewegt hat und was seit einem Vierteljahr offen steht. Wenn du deine Seite ohnehin neu aufsetzt, gehören die Prüfpunkte gleich in den Bauplan, dazu steht das Nötige in Website erstellen lassen. Und wenn du den Schritt dahinter gehen willst, also einen KI-Mitarbeiter, der gestuft prüft und jeden Fund belegt statt nur eine Note auszugeben: Der Weg dorthin und die fertigen Rollen liegen in meiner Community Claude Practitioners.