Leitfaden

Website-Sicherheit prüfen: Schritt für Schritt selbst testen

Von Lucas Weber, CyberSec42 · Stand 28.10.2026

Website-Sicherheit prüfen können Sie als Inhaber eines kleinen Betriebs zu einem guten Teil selbst, mit dem Browser und einigen kostenlosen Werkzeugen: Verschlüsselung und Zertifikat, Security-Header, veraltete Software, offene Admin-Logins, den Malware- und Blacklist-Status, öffentlich abrufbare Dateien, Formulare und die Absender-Einstellungen Ihrer E-Mails. Diese Anleitung zeigt je Punkt, wie Sie prüfen, was das Ergebnis bedeutet und was Sie tun, wenn etwas auffällt. Was kein automatischer Test findet, sind Fehler in der Logik und in den Zugriffsrechten Ihrer Seite. Dafür braucht es eine Prüfung durch einen Menschen.

Bevor Sie anfangen

Prüfen Sie nur Ihre eigene Website oder eine Seite, für deren Prüfung Sie eine Erlaubnis haben. Alle Werkzeuge in dieser Anleitung rufen Ihre Seite so auf, wie es ein Besucher tut, und lesen aus, was sie öffentlich zeigt. Das ist für die eigene Seite unproblematisch.

Legen Sie sich eine einfache Liste an: Prüfpunkt, Ergebnis, Datum, offene Frage. Was Sie nicht selbst beantworten können, geht als Frage an Ihren Hoster, Ihre Agentur oder Ihren Baukasten-Anbieter. Wie Sie die Grundlagen absichern, also Zugänge, Zwei-Faktor-Anmeldung, Backups und Verträge, beschreibt unser Beitrag Website-Sicherheit für kleine Unternehmen. Hier geht es um das Messen: Was sieht ein Fremder, wenn er Ihre Seite von außen untersucht?

1. HTTPS und Zertifikat prüfen

Das Zertifikat ist der digitale Ausweis Ihrer Seite. Es sorgt dafür, dass Eingaben wie Name, E-Mail-Adresse oder Passwort verschlüsselt übertragen werden. Dass im Browser ein Schloss erscheint, ist der erste Schritt. Wie gut die Verschlüsselung eingerichtet ist, zeigt ein genauerer Test.

So prüfen Sie

• Öffnen Sie den kostenlosen SSL Server Test von Qualys SSL Labs und geben Sie Ihre Domain ein. Setzen Sie vorher das Häkchen bei „Do not show the results on the boards“, wenn Ihr Ergebnis nicht in den öffentlichen Listen des Dienstes erscheinen soll.
• Tippen Sie Ihre Adresse zusätzlich einmal mit http:// ein. Sie sollten automatisch auf die https://-Fassung umgeleitet werden.

So lesen Sie das Ergebnis

Achten Sie im Bericht auf zwei Angaben. Erstens das Ablaufdatum des Zertifikats und die Frage, ob es sich automatisch verlängert. Zweitens die Protokolle: Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt in seiner Technischen Richtlinie TR-02102-2 (Fassung 2026-01) vorrangig TLS 1.3, TLS 1.2 nur noch bis Ende 2031 und TLS 1.0 und 1.1 gar nicht mehr. Die beiden alten Versionen hat die Internet Engineering Task Force mit RFC 8996 auch formal für veraltet erklärt. Stehen sie im Bericht noch auf „Yes“, ist das eine konkrete Frage an Ihren Hoster.

Bei Baukästen wie Wix, Jimdo oder Shopify richtet der Anbieter die Verschlüsselung ein. Eine Note unter A ist dort kein Grund zur Sorge, denn Sie können sie ohnehin nicht ändern.

2. Security-Header messen

Security-Header sind kurze Anweisungen, die Ihre Seite bei jedem Aufruf an den Browser mitschickt, etwa „lade diese Seite nur verschlüsselt“ oder „lass dich nicht in fremde Seiten einbetten“. Sie schützen Besucher vor einigen verbreiteten Angriffen, zum Beispiel vor eingeschleusten Skripten oder vor Seiten, die Ihre Seite unsichtbar überlagern.

So prüfen Sie

Geben Sie Ihre Domain in das kostenlose HTTP Observatory von Mozilla ein. Es vergibt eine Note von A+ bis F, ausgehend von 100 Punkten, und zeigt je Test, was fehlt. Laut Mozilla lässt sich eine Seite höchstens einmal pro Minute neu prüfen.

Ein Beispiel vom eigenen Haus: Für www.cybersec42.com meldete das Observatory am 28.10.2026 die Note A+ mit 110 Punkten, 12 von 12 Tests bestanden. Eine zweite Messung per direktem Abruf der Seite bestätigt die Header, die dahinterstehen:

strict-transport-security: max-age=63072000; includeSubDomains; preload
content-security-policy: default-src 'self'; script-src 'self' 'sha256-…' …
x-content-type-options: nosniff
x-frame-options: DENY
referrer-policy: strict-origin-when-cross-origin
permissions-policy: geolocation=(), microphone=(), camera=(), …

So lesen Sie das Ergebnis

Fehlen Header, ist das eine Aufgabe für Ihren Dienstleister, kein Notfall. Wie die einzelnen Header wirken und wie man sie für Apache, nginx, Netlify oder Vercel einrichtet, steht in unserem Beitrag Content Security Policy und Security-Header. Wichtig ist die Grenze des Werkzeugs: Mozilla schreibt in seinen häufigen Fragen selbst, dass auch ein A+ nicht bedeutet, dass eine Seite sicher ist. Veraltete Software, verwundbare Plugins, SQL-Injection oder der Umgang mit Passwörtern werden nicht geprüft.

3. Veraltete CMS- und Plugin-Versionen finden

Ein Content-Management-System (CMS) ist die Software, mit der Sie Ihre Seite pflegen, zum Beispiel WordPress, Joomla oder TYPO3. Plugins und Themes sind Erweiterungen dafür. Für viele bekannte Lücken in solcher Software gibt es längst ein Update. Angriffsprogramme suchen gezielt nach Seiten, auf denen es fehlt.

So prüfen Sie bei WordPress

• Öffnen Sie im Verwaltungsbereich Werkzeuge → Website-Zustand. WordPress zeigt dort unter „Status“ kritische Probleme an, darunter wartende Plugin-Updates, eine veraltete PHP-Version oder eingeschaltete Fehlerausgaben, und unter „Info“ die Versionen von WordPress, Theme und allen Plugins (WordPress-Dokumentation).
• Sehen Sie unter Dashboard → Aktualisierungen nach, ob Updates warten, und unter Plugins, ob deaktivierte Plugins herumliegen. Was Sie nicht nutzen, löschen Sie, statt es nur zu deaktivieren.
• Prüfen Sie bei jedem Plugin auf seiner Seite im WordPress-Verzeichnis, wann es zuletzt aktualisiert wurde. Ein Plugin, das seit Jahren keine Pflege mehr bekommt, bekommt auch keine Sicherheitsupdates mehr.

Bei anderen Systemen

Bei Baukästen aktualisiert der Anbieter das System selbst. Ihre Aufgabe sind installierte Apps und Erweiterungen von Drittanbietern. Betreut eine Agentur Ihre Seite, bitten Sie um eine Liste aller eingesetzten Komponenten mit Versionsnummer und Datum des letzten Updates. Wenn diese Liste niemand liefern kann, haben Sie Ihren wichtigsten Befund schon gefunden. Wie Sie WordPress dauerhaft aktuell halten, beschreibt unser WordPress-Leitfaden.

4. Offene Admin-Logins

Die Anmeldeseite Ihres Verwaltungsbereichs ist die Tür mit dem größten Schlüsselbund. Bei WordPress liegt sie standardmäßig unter /wp-admin/, bei Joomla unter /administrator/. Der Prüfleitfaden der OWASP, einer gemeinnützigen Organisation für Anwendungssicherheit, führt solche Pfade ausdrücklich als typische Ziele auf, weil Verwaltungsoberflächen oft nicht ausreichend vor fremdem Zugriff geschützt sind (OWASP WSTG).

So prüfen Sie

• Rufen Sie die Anmeldeseite in einem privaten Browserfenster auf, am besten auch einmal über das Mobilfunknetz statt über Ihr Büro-WLAN. Ist sie von überall erreichbar, ist das bei vielen Seiten normal. Dann muss die Anmeldung selbst stark geschützt sein.
• Ist für jedes Konto mit Verwaltungsrechten eine Zwei-Faktor-Anmeldung eingeschaltet?
• Gibt es weitere Verwaltungsoberflächen, etwa eine Datenbankverwaltung wie phpMyAdmin unter Ihrer Domain? Die gehört nicht ins offene Netz. Fragen Sie Ihren Hoster, wo sie erreichbar ist.
• Fragen Sie Ihren Dienstleister, ob wiederholte Fehlversuche bei der Anmeldung gebremst oder gesperrt werden. Probieren Sie das nicht selbst mit vielen Versuchen aus, sonst sperren Sie womöglich Ihr eigenes Konto.

Ein gutes Ergebnis: Nur bekannte Personen haben Verwaltungsrechte, alle mit zweitem Faktor, und Datenbank- oder Server-Verwaltung ist nicht öffentlich erreichbar.

5. Malware- und Blacklist-Status prüfen

Wird auf Ihrer Seite Schadsoftware oder eine Betrugsseite gefunden, setzt Google sie auf eine Sperrliste. Browser zeigen Besuchern dann eine Warnung, bevor sie die Seite öffnen. Das merken Sie oft zuletzt, weil Ihr eigener Browser die Seite aus dem Speicher lädt.

So prüfen Sie

• Google Safe Browsing Site Status: Im Transparenzbericht von Google geben Sie Ihre Domain ein und sehen, ob Google sie derzeit als gefährlich einstuft. Safe Browsing erkennt nach Googles Entwicklerdokumentation Phishing- und Täuschungsseiten sowie Seiten, die Malware oder unerwünschte Software verbreiten. Gewünscht ist ein Ergebnis ohne Hinweis auf unsichere Inhalte.
• Google Search Console: Der Bericht „Sicherheitsprobleme“ meldet gehackte Inhalte, Malware und unerwünschte Software sowie Social Engineering, also Inhalte, die Besucher zu riskanten Handlungen verleiten sollen (Search-Console-Hilfe). Dafür brauchen Sie einen eigenen Zugang zur Search Console.
• Suche nach fremden Inhalten: Geben Sie bei Google site:ihre-domain.de ein und blättern Sie durch die Treffer. Seiten in fremder Sprache, Arzneimittel- oder Glücksspielwerbung, die Sie nie angelegt haben, sind ein Warnzeichen.

So lesen Sie das Ergebnis

Ein sauberes Ergebnis heißt nur, dass Google derzeit nichts gemeldet hat. Manche Schadsoftware zeigt sich nur bestimmten Besuchern, etwa nur Smartphones oder nur Besuchern, die über die Suche kommen. Steht Ihre Seite auf der Liste oder finden Sie fremde Inhalte, behandeln Sie das als Einbruch und folgen Sie unserem Beitrag Website gehackt: was tun?. Dort steht auch, wie Sie nach der Bereinigung eine Überprüfung bei Google beantragen.

6. Öffentlich auffindbare Dateien: Backups, .git, .env

Einer der folgenreichsten Fehler ist zugleich einer der einfachsten: Eine Datei liegt im öffentlichen Bereich des Servers, die dort nicht hingehört. Wer die Adresse errät, lädt sie herunter. Der Prüfleitfaden der OWASP nennt dafür drei Gruppen, die grundsätzlich nie öffentlich ausgeliefert werden sollten (OWASP WSTG):

• Sicherungskopien und Archive wie .zip, .tar.gz, .bak oder .old. Ein vollständiges Backup enthält oft die ganze Seite samt Datenbank, also auch Kundendaten und Passwort-Hashes.
• Konfigurationsdateien wie .env. Darin stehen häufig Zugangsdaten für Datenbank, Mailserver oder Zahlungsdienste im Klartext.
• Der Ordner .git, den das Versionswerkzeug Git anlegt. Ist er erreichbar, lässt sich daraus oft der gesamte Quellcode samt früherer Stände rekonstruieren, auch Passwörter, die irgendwann einmal eingetragen und später wieder gelöscht wurden.

Auch WordPress warnt im Website-Zustand, wenn Fehlermeldungen in eine Protokolldatei geschrieben werden, die möglicherweise öffentlich abrufbar ist.

So prüfen Sie

Hängen Sie in einem privaten Browserfenster diese Pfade an Ihre Domain an und sehen Sie sich an, was zurückkommt:

https://ihre-domain.de/.git/HEAD
https://ihre-domain.de/.env
https://ihre-domain.de/backup.zip
https://ihre-domain.de/wp-content/debug.log

So lesen Sie das Ergebnis

• Gut: eine Fehlerseite „nicht gefunden“ oder „Zugriff verweigert“. Für www.cybersec42.com liefern /.git/HEAD und /.env zum Beispiel einen Fehler 404.
• Vorsicht: Manche Server zeigen bei unbekannten Adressen einfach Ihre Startseite. Entscheidend ist der Inhalt, nicht die Frage, ob „etwas lädt“.
• Sofort handeln: Sie sehen eine Zeile wie ref: refs/heads/main, Zugangsdaten oder ein Download startet. Lassen Sie die Datei entfernen und betrachten Sie alle Passwörter und Schlüssel darin als bekannt: Sie müssen ersetzt werden, nicht nur die Datei gelöscht.

Ein unauffälliges Ergebnis ist hier besonders wenig wert. Sie haben vier naheliegende Namen geprüft, eine vergessene Datei heißt aber vielleicht seite-alt-2023.zip. Fragen Sie deshalb zusätzlich Ihren Dienstleister, ob im Webverzeichnis Sicherungen, Exporte oder Kopien liegen, und lassen Sie sie an einen Ort außerhalb des öffentlichen Bereichs verschieben.

7. Formulare und Spam

Ihr Kontaktformular ist die Stelle, an der Fremde Daten auf Ihren Server schicken. Spam ist dabei das sichtbare Problem. Wichtiger ist, was das Formular annimmt und wohin die Daten gehen.

• Selbst ausfüllen: Senden Sie eine Testnachricht. Kommt sie an? Wird sie zusätzlich in der Website gespeichert, und wer kann sie dort lesen?
• Uploads: Erlaubt das Formular Datei-Anhänge? Dann sollte es nur bestimmte Dateiarten annehmen, etwa PDF, und hochgeladene Dateien dürfen nicht öffentlich abrufbar sein.
• Kopie an den Absender: Schickt das Formular eine Kopie an die eingetragene Adresse, lässt es sich missbrauchen, um über Ihren Server Nachrichten an beliebige Empfänger zu senden. Prüfen Sie, ob diese Funktion nötig ist.
• Spam-Schutz: Gibt es einen Schutz gegen automatische Einsendungen? Wenn Ihr Postfach mit Spam aus dem Formular voll ist, fehlt er oder greift nicht.

Was Sie von außen nicht sehen: ob der Server die Eingaben selbst noch einmal prüft oder sich auf die Prüfung im Browser verlässt. Dieser Unterschied ist ein klassischer Ansatzpunkt für Angriffe und gehört zu den Dingen, die erst eine manuelle Prüfung zeigt.

8. E-Mail-Absender: SPF, DKIM und DMARC kurz geprüft

Diese drei Einträge im Namenssystem Ihrer Domain (DNS) legen fest, wer E-Mails in Ihrem Namen versenden darf. Fehlen sie, können Betrüger leichter Nachrichten verschicken, die scheinbar von Ihrer Adresse kommen, etwa gefälschte Rechnungen an Ihre Kunden.

So prüfen Sie

• Schicken Sie sich von Ihrer Firmenadresse eine Mail an ein Gmail-Postfach. Öffnen Sie sie im Browser, klicken Sie auf die drei Punkte neben „Antworten“ und dann auf „Original anzeigen“ (Gmail-Hilfe). Oben steht eine Übersicht mit SPF, DKIM und DMARC. Gut ist, wenn dort jeweils PASS steht.
• Fehlt einer der drei Einträge, fragen Sie Ihren E-Mail- oder Domain-Anbieter.

DMARC kennt laut Standard RFC 7489 drei Stufen: p=none (nur beobachten und Berichte sammeln), p=quarantine (verdächtige Mails etwa im Spam-Ordner ablegen) und p=reject (abweisen). Üblich ist, mit none zu beginnen, die Berichte zu lesen und erst dann zu verschärfen. Google verlangt seit dem 1. Februar 2024 von allen Absendern an Gmail mindestens SPF oder DKIM, von Absendern mit mehr als 5.000 Mails pro Tag SPF, DKIM und DMARC (Google-Richtlinien für E-Mail-Absender). Für die Zustellbarkeit Ihrer Mails lohnt sich die Einrichtung also doppelt.

Website auf Sicherheitslücken prüfen: wo Werkzeuge aufhören

Die acht Prüfungen oben zeigen, wie Ihre Seite von außen eingerichtet ist. Automatische Werkzeuge, auch kostenpflichtige Online-Scanner, vergleichen das Gesehene mit bekannten Mustern. Was sie grundsätzlich nicht beurteilen können, ist die Frage, ob Ihre Seite das tut, was sie tun soll, und nur das:

• Zugriffsrechte: Sieht ein angemeldeter Kunde nur seine eigenen Bestellungen, Termine oder Rechnungen? Oder reicht es, in der Adresszeile eine Nummer zu ändern, um die eines anderen Kunden zu sehen? Ein Scanner kennt Ihre Kunden nicht und kann den Unterschied nicht erkennen.
• Logikfehler: Lässt sich ein Gutschein mehrfach einlösen, ein Preis im Warenkorb verändern, ein Bestellschritt überspringen oder ein Passwort über die „Passwort vergessen“-Funktion fremd zurücksetzen? Technisch ist dabei alles in Ordnung, nur die Regel stimmt nicht.
• Eigene Funktionen: Rechner, Konfiguratoren, Schnittstellen zur Warenwirtschaft oder zum Kalender. Für eigens programmierten Code gibt es keine bekannte Lücke in einer Datenbank, also auch keinen Treffer im Scanner.
• Was hinter der Anmeldung liegt: Die meisten Online-Werkzeuge sehen nur die öffentlichen Seiten. Kundenbereich, Verwaltung und Schnittstellen bleiben ungeprüft.

Deshalb gilt: Für eine reine Informationsseite mit Kontaktformular reichen die acht Prüfungen, regelmäßig wiederholt. Sobald Ihre Seite einen Shop, ein Kundenkonto, ein Buchungssystem oder eigene Funktionen hat, lohnt sich eine manuelle Prüfung, bei der ein Mensch die Seite mit mehreren Testkonten so durchgeht, wie es ein Angreifer täte. Was dabei passiert, erklärt unser Beitrag Penetrationstest: Ablauf, Dauer und Kosten. Wer zuerst einen breiten Überblick möchte, findet den Unterschied zur Schwachstellenanalyse dort erklärt.

Website-Sicherheit prüfen: die Checkliste

Wiederholen Sie die Liste einmal im Quartal und nach jeder größeren Änderung an der Seite, etwa nach einem neuen Plugin oder einem Wechsel des Dienstleisters. Die Datenschutz-Grundverordnung verlangt für Systeme mit personenbezogenen Daten ohnehin ein Verfahren zur regelmäßigen Überprüfung der Schutzmaßnahmen (Art. 32 Abs. 1 lit. d DSGVO). Was das für Ihren Betrieb konkret bedeutet, ist eine Rechtsfrage. Dieser Artikel ist keine Rechtsberatung.

Häufige Fragen

Weiterlesen

• Website-Sicherheit für kleine Unternehmen: selbst prüfen und absichern
• Content Security Policy und Security-Header
• WordPress absichern: der praktische Leitfaden für Unternehmen
• Website gehackt: was tun? Die ersten Schritte
• Shopify-Shop absichern: was Sie als Händler selbst tun müssen
• Leistung: Penetrationstest mit verifizierten Befunden

Quellen

• BSI: Technische Richtlinie TR-02102-2, Verwendung von Transport Layer Security (Fassung 2026-01)
• IETF RFC 8996: Deprecating TLS 1.0 and TLS 1.1
• IETF RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• EUR-Lex: Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung), Art. 32
• OWASP Web Security Testing Guide: Review Old Backup and Unreferenced Files for Sensitive Information
• OWASP Web Security Testing Guide: Enumerate Infrastructure and Application Admin Interfaces
• MDN HTTP Observatory: Frequently asked questions
• MDN HTTP Observatory: Tests and scoring
• Qualys SSL Labs: SSL Server Test
• Qualys SSL Labs: SSL Server Rating Guide
• Google Transparenzbericht: Safe Browsing Site Status
• Google for Developers: Safe Browsing
• Search-Console-Hilfe: Bericht „Sicherheitsprobleme“
• Google: Richtlinien für E-Mail-Absender
• WordPress-Dokumentation: Site Health screen