Kurz gesagt: Ein Sicherheitscheck von außen sieht sich Ihre Website so an, wie ein Angreifer sie sieht: Verschlüsselung, HTTP-Header, frei abrufbare Dateien, Software-Versionen, Formulare und E-Mail-Einstellungen. Vieles davon können Sie mit dem Browser selbst testen. Ein automatischer Scan findet typische Schwachstellen, eine Garantie für eine sichere Website gibt er nicht. Prüfen Sie nur Seiten, die Ihnen gehören oder für die Sie eine Erlaubnis haben.
Warum Sie die Sicherheit Ihrer Website prüfen sollten
Kleine Websites werden selten gezielt ausgesucht. Angreifer lassen automatisierte Programme durch das Netz laufen, die nach bekannten Sicherheitslücken suchen: ein altes Plugin, ein offenes Verzeichnis, ein schwaches Passwort am Login. Findet ein solches Programm eine Lücke, nutzt es sie aus. Danach verteilt die Seite vielleicht Malware, leitet Besucher auf Phishing-Seiten weiter oder verschickt Spam.
Für Sie als Betreiber hat das handfeste Folgen. Browser und Google warnen vor der Seite, Kunden verlieren Vertrauen, und wenn persönliche Daten abfließen, kommen rechtliche Pflichten dazu. Ein regelmäßiger Website-Check senkt dieses Risiko. Er zeigt Schwachstellen, bevor andere sie finden.
Was ein Sicherheitscheck von außen prüft
Ein externer Security-Check braucht keinen Zugang zu Ihrem Server. Er ruft die Website auf, liest die Antworten des Webservers aus und testet bekannte Adressen. Diese Bereiche gehören dazu:
HTTPS und TLS
Die Verbindung zwischen Browser und Server sollte immer verschlüsselt sein. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt Transportverschlüsselung für Webanwendungen grundsätzlich. Ein Scan prüft, ob das SSL-Zertifikat gültig ist und bald abläuft, ob alte Protokollversionen noch erlaubt sind und ob jede Adresse mit http:// sauber auf https:// weiterleitet. Zeigt der Browser „Nicht sicher“ an, fehlt meist genau diese Verschlüsselung oder ein Teil der Seite lädt noch über HTTP.
Security-Header
Mit bestimmten HTTP-Headern sagt der Server dem Browser, wie er sich verhalten soll. Beispiele sind Strict-Transport-Security (nur HTTPS erlauben), Content-Security-Policy (nur freigegebene Skripte laden) und X-Content-Type-Options. Fehlen sie, hat ein Angreifer bei Cross-Site-Scripting (XSS) oder Clickjacking leichteres Spiel. Was die einzelnen Header tun, erklären wir im Artikel Security-Header einfach erklärt.
Offene Dateien und Verzeichnisse
Ein häufiger Fehler bei kleinen Websites: Dateien liegen im öffentlichen Ordner, die dort nichts zu suchen haben. Ein Scanner fragt gezielt URLs ab, zum Beispiel diese:
https://example.com/.env https://example.com/.git/config https://example.com/backup.zip https://example.com/wp-config.php.bakEine .env-Datei enthält oft Datenbank-Passwörter und API-Schlüssel. Aus einem offenen .git-Ordner lässt sich manchmal der komplette Quellcode laden. Liefert eine dieser Adressen Inhalt statt einer Fehlermeldung, ist das eine ernste Lücke.
Zugangsschlüssel im JavaScript
Alles, was der Browser lädt, kann jeder Besucher lesen. Steht ein geheimer Schlüssel für einen Zahlungsdienst, einen Mailversand oder eine Datenbank im JavaScript-Code, ist er öffentlich. Ein Scan durchsucht die geladenen Skripte nach typischen Mustern solcher Schlüssel. Öffentliche Schlüssel, die für den Browser gedacht sind, sind dabei kein Problem.
Veraltete Software und Plugins
Viele Systeme verraten ihre Version: im Quelltext, in Dateinamen oder in einem Header wie Server: Apache/2.4.x oder X-Powered-By: PHP/8.x. Ein Scanner gleicht diese Angaben mit bekannten Schwachstellen ab. Bei WordPress, TYPO3 und anderen CMS betrifft das vor allem Erweiterungen, die lange keine Updates bekommen haben.
Formulare und Login
Kontaktformulare, Suchfelder und Logins nehmen Eingaben an. Ein Check schaut, ob Formulare über HTTPS senden, ob der Login gegen viele Fehlversuche geschützt ist und ob Fehlermeldungen technische Details verraten. Tiefere Tests auf SQL-Injection oder XSS gehören eher in einen Penetrationstest.
E-Mail-Einstellungen der Domain
Auch die Domain selbst gehört zur Sicherheit. Fehlen SPF, DKIM und DMARC, können Betrüger E-Mails mit Ihrer Absenderadresse verschicken. Ein Check fragt die DNS-Einträge ab und meldet Lücken. Wie Sie das einrichten, steht im Artikel SPF, DKIM und DMARC.
OWASP Top 10:2025: die größten Risiken für Webanwendungen
Das Open Worldwide Application Security Project (OWASP) veröffentlicht eine Liste der wichtigsten Sicherheitsrisiken für Webanwendungen. Auch das BSI verweist darauf. Die Ausgabe 2025 nennt diese zehn Kategorien:
- Broken Access Control: Nutzer kommen an Daten oder Funktionen, die nicht für sie bestimmt sind.
- Security Misconfiguration: falsche oder fehlende Einstellungen, etwa offene Dateien oder fehlende Header.
- Software Supply Chain Failures: Probleme in fremden Bausteinen wie Bibliotheken, Plugins oder Build-Werkzeugen.
- Cryptographic Failures: schwache oder fehlende Verschlüsselung.
- Injection: eingeschleuster Code, zum Beispiel SQL-Injection oder Cross-Site-Scripting.
- Insecure Design: Fehler schon im Konzept einer Anwendung.
- Authentication Failures: Schwächen beim Login, etwa fehlender Schutz gegen Passwort-Raten.
- Software or Data Integrity Failures: Code oder Daten werden ohne Prüfung übernommen.
- Security Logging and Alerting Failures: Angriffe bleiben unbemerkt, weil niemand protokolliert oder Alarm schlägt.
- Mishandling of Exceptional Conditions: Die Anwendung reagiert auf Fehler und Sonderfälle unsicher.
Auffällig: Security Misconfiguration ist von Platz 5 in der Ausgabe 2021 auf Platz 2 gestiegen. Genau diese Fehler findet ein Scan von außen gut. Für kleine Websites sind außerdem die Punkte Supply Chain und Authentication wichtig, weil sie Plugins und Passwörter betreffen.
Was Sie selbst prüfen können
Für einen ersten Überblick brauchen Sie kein spezielles Tool. Ein aktueller Browser und etwas Zeit reichen.
Schritt-für-Schritt-Anleitung mit den Entwicklertools
- Öffnen Sie Ihre Website und drücken Sie F12. Die Entwicklertools gehen auf.
- Wechseln Sie zum Reiter „Netzwerk“ und laden Sie die Seite neu.
- Klicken Sie auf den ersten Eintrag, also das HTML-Dokument. Unter „Antwort-Header“ sehen Sie, was der Server mitschickt.
- Suchen Sie nach Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options und Referrer-Policy.
- Schauen Sie im Reiter „Konsole“ nach Warnungen zu gemischten Inhalten (Mixed Content). Sie zeigen Dateien, die noch über HTTP laden.
Wer ein Terminal nutzt, kommt mit einem Befehl zum gleichen Ergebnis:
curl -I https://example.comDie Antwort zeigt alle Header der Startseite. Steht dort zum Beispiel X-Powered-By: PHP/7.4.3, verrät der Server eine Version, die längst keine Sicherheitsupdates mehr bekommt.
Offene Dateien testen
Rufen Sie die Adressen aus dem Beispiel oben für Ihre eigene Domain im Browser auf. Gut ist eine Fehlerseite (404 oder 403). Schlecht ist jede Antwort, die Inhalt zeigt oder eine Datei herunterlädt.
Update-Stand kontrollieren
Melden Sie sich im Backend Ihres CMS an und prüfen Sie, ob Kern, Theme und alle Plugins aktuell sind. Löschen Sie Erweiterungen, die Sie nicht mehr nutzen; ein deaktiviertes Plugin liegt trotzdem auf dem Server. Fragen Sie beim Hosting nach, welche PHP-Version läuft. Falls Sie Hilfe bei WordPress brauchen, lesen Sie unseren Artikel zur WordPress-Agentur.
Angebote von Mozilla und Google
Mozilla bietet auf MDN das HTTP Observatory an. Es bewertet die Security-Header einer Website und erklärt, was fehlt. In der Google Search Console finden Sie den Bericht „Sicherheitsprobleme“. Dort meldet Google, wenn es auf Ihrer Website Malware, gehackte Inhalte oder Phishing erkannt hat.
Grenzen eines automatischen Scans
Ein automatisierter Website-Check sieht nur, was von außen erreichbar ist. Er kennt Ihre Passwörter nicht, sieht keine Server-Einstellungen und kann Geschäftslogik nicht verstehen. Ob ein Kunde über eine geänderte Bestellnummer fremde Rechnungen abrufen kann, merkt ein Scanner meist nicht. Solche Fehler fallen unter Broken Access Control und brauchen einen Menschen, der gezielt testet.
Ein Scan liefert außerdem Fehlalarme und übersieht manches. Ein sauberer Report heißt deshalb nur: Die geprüften Punkte waren in Ordnung. Für Online-Shops, Portale mit Benutzerkonten oder Anwendungen mit Kundendaten lohnt sich zusätzlich ein Penetrationstest. Dabei greifen Fachleute die Anwendung mit Ihrer Erlaubnis manuell an und gehen deutlich tiefer.
Nur eigene Seiten scannen
Ein Sicherheitsscan schickt viele gezielte Anfragen an einen Server. Bei fremden Websites kann das als Angriffsversuch gelten und rechtliche Folgen haben. Prüfen Sie deshalb nur Websites, die Ihnen gehören oder für die Sie eine schriftliche Erlaubnis des Betreibers haben. Das gilt auch, wenn Ihre Website bei einem Hoster oder einer Agentur liegt: Klären Sie vorher, ob Scans erlaubt sind. Dieser Hinweis ist keine Rechtsberatung; bei Unsicherheit fragen Sie eine Fachanwältin oder einen Fachanwalt.
In welcher Reihenfolge Sie Lücken beheben
Nach dem Check haben Sie meist eine lange Liste. Arbeiten Sie sie nach Risiko ab:
- Offene Geheimnisse: Liegt eine .env-Datei, ein Backup oder ein Schlüssel öffentlich, löschen Sie die Datei sofort. Ändern Sie danach alle betroffenen Passwörter und Schlüssel, denn Sie wissen nicht, wer sie schon kopiert hat.
- Bekannte Schwachstellen: CMS, Plugins und PHP aktualisieren. Für viele Lücken gibt es längst ein Update.
- Zugänge: starke Passwörter, Zwei-Faktor-Anmeldung für Admins, alte Benutzerkonten entfernen.
- Verschlüsselung: HTTPS überall, Weiterleitung von HTTP, keine gemischten Inhalte.
- Header: zuerst X-Content-Type-Options und Referrer-Policy, dann HSTS stufenweise, zuletzt eine Content-Security-Policy im Testmodus.
- E-Mail: SPF, DKIM und DMARC für die Domain einrichten.
- Versionsangaben: Header wie X-Powered-By ausblenden, damit der Server weniger über sich verrät.
Legen Sie vor jeder Änderung ein Backup an und testen Sie danach, ob Formulare, Shop und Login noch funktionieren. Wiederholen Sie den Check nach jedem größeren Update und sonst regelmäßig, zum Beispiel einmal im Monat.
Fazit
Ein Sicherheitscheck von außen deckt die häufigsten Fehler kleiner Websites auf: fehlende Verschlüsselung, fehlende Header, offene Dateien, alte Plugins und ungeschützte E-Mail-Domains. Vieles davon prüfen Sie mit Browser und curl selbst. Für Anwendungen mit Kundendaten kommt ein manueller Test dazu. Weitere Grundlagen finden Sie auf unserer Themenseite Webseiten-Sicherheit.
Quellen: OWASP, „OWASP Top 10:2025“ (owasp.org/Top10/2025); BSI, Informationen zu Webanwendungen; MDN Web Docs, HTTP-Header und HTTP Observatory; Google Search Console Hilfe, Bericht „Sicherheitsprobleme“.