Website-Sicherheit selbst prüfen: Was du ohne Werkzeuge siehst

Man muss kein Sicherheitsfachmann sein, um die häufigsten Schwachstellen der eigenen Website zu finden. Ein erheblicher Teil dessen, was in professionellen Prüfberichten auftaucht, lässt sich mit dem Browser und einer Handvoll kostenloser Dienste in zwanzig Minuten selbst feststellen. Dieser Text zeigt, wie — und wo die Grenze liegt, hinter der Selbstprüfung nicht mehr weiterhilft.

Teil 1: Was der Browser allein zeigt

1. Verschlüsselung und Zertifikat

Klick auf das Schloss neben der Adresse. Dort steht, wer das Zertifikat ausgestellt hat und bis wann es gilt. Drei Dinge sind zu prüfen:

• Läuft es bald ab? Zertifikate von Let's Encrypt gelten 90 Tage und werden normalerweise automatisch erneuert. Bleiben weniger als 20 Tage, funktioniert die Erneuerung wahrscheinlich nicht mehr.
• Passt der Name? Ein Zertifikat für deine-seite.de deckt www.deine-seite.de nicht automatisch mit ab.
• Gilt es auch für Unterdomains, die du benutzt — Shop, Blog, Kundenbereich?

2. Die vier Adressvarianten

Ruf deine Seite in allen vier Schreibweisen auf:

http://deine-seite.de
http://www.deine-seite.de
https://deine-seite.de
https://www.deine-seite.de

Alle vier müssen bei derselben verschlüsselten Adresse landen. Bleibt eine davon unverschlüsselt erreichbar, nützt das beste Zertifikat wenig — dann gibt es die Seite zweimal, einmal geschützt und einmal nicht.

3. Gemischte Inhalte

Entwicklerwerkzeuge öffnen (F12), Reiter Konsole, Seite neu laden. Warnungen über „mixed content“ bedeuten: Die Seite läuft über HTTPS, lädt aber einzelne Bilder oder Skripte unverschlüsselt nach. Der Browser zeigt dann trotzdem ein Schloss — geschützt ist die Seite nicht vollständig.

4. Welche fremden Dienste laden

Reiter Netzwerk, Seite neu laden, Spalte „Domain“ ansehen. Jede fremde Domain in dieser Liste ist ein Dienst, der die IP-Adresse deiner Besucher erhält — und der in der Datenschutzerklärung stehen muss. Häufige Funde: Schriften, Kartendienste, Bewertungssiegel, Chat-Fenster, Bibliotheken von einem CDN.

Wichtig dabei: auf mehreren Seitentypen prüfen. Die Startseite ist oft sauber, während das Kontaktformular noch etwas nachlädt.

5. Cookies vor der Einwilligung

Privates Fenster öffnen, Seite laden, nichts anklicken, dann unter Anwendung → Cookies und im lokalen Speicher nachsehen. Alles außer einer Sitzungskennung und dem Einwilligungs-Cookie selbst ist ein Befund.

6. Tastaturbedienung

Gehört formal zur Barrierefreiheit, hat aber praktische Sicherheitsbezüge: Ein Cookie-Banner, aus dem man per Tastatur nicht herauskommt, sperrt Besucher aus. Leg die Maus weg und geh mit der Tabulatortaste durch die Seite.

Teil 2: Was ein Blick in den Quelltext verrät

Rechtsklick → Seitenquelltext anzeigen. Zwei Dinge lohnen die Suche:

• Versionsangaben. Viele Systeme schreiben ihre Version in einen generator-Eintrag im Kopfbereich. Wer weiß, welche Version läuft, kann gezielt nach passenden Lücken suchen. Die Angabe lässt sich entfernen — das ist keine Sicherheit für sich, aber es nimmt Gelegenheitssuchern die Vorarbeit.
• Kommentare. Gelegentlich stehen dort Hinweise auf Testzugänge, interne Adressen oder Namen von Systemen, die nicht öffentlich sein sollten.

Teil 3: Was der Server ausplaudert

Auf der Kommandozeile — verfügbar auf jedem Mac und unter Windows über die Eingabeaufforderung:

curl -sI https://deine-seite.de

Die Antwort zeigt die Kopfzeilen. Interessant sind zwei Gruppen:

Wer curl nicht nutzen will: Die Kopfzeilen stehen auch in den Entwicklerwerkzeugen unter Netzwerk, wenn man die erste Anfrage anklickt.

Teil 4: Dateien, die niemand sehen sollte

Das ist der Bereich mit den folgenreichsten Funden. Ruf diese Adressen für deine eigene Seite auf:

• /.env — Konfiguration mit Datenbankzugängen und Schlüsseln
• /.git/config — verrät, ob der Quellcode mit heruntergeladen werden kann
• /backup.sql, /backup.zip, /dump.sql
• /wp-config.php.bak, /config.php.save, /.env.bak
• /phpinfo.php, /info.php — verraten die komplette Serverkonfiguration
• /server-status — bei Apache manchmal offen erreichbar

Erwartet wird jeweils eine Fehlerseite. Kommt stattdessen ein Download oder Klartext, ist das der dringendste Punkt auf der Liste — dringender als jede fehlende Kopfzeile. Wer eine Konfigurationsdatei mit Zugangsdaten findet, braucht keine Sicherheitslücke mehr.

Der häufigste Entstehungsweg: Jemand legt vor einer Änderung schnell eine Sicherungskopie an, nennt sie .bak und vergisst sie. Dateien mit dieser Endung liefert der Server als reinen Text aus, statt sie wie PHP-Dateien auszuführen.

Teil 5: Kostenlose Dienste, die weiterhelfen

Diese Dienste haben eine Gemeinsamkeit: Sie prüfen jeweils einen Aspekt gründlich. Wer einen Gesamteindruck will, muss mehrere kombinieren und die Ergebnisse selbst zusammenführen — genau dafür gibt es Werkzeuge, die alles in einem Durchgang messen.

WordPress: die fünf Stellen, an denen es meistens klemmt

Rund vier von zehn deutschen Websites laufen mit WordPress. Entsprechend ähneln sich die Funde:

1. Die Anmeldeseite ist offen und unbegrenzt. /wp-login.php ist bei fast jeder Installation erreichbar und wird durchgehend automatisiert durchprobiert. Abhilfe: Begrenzung der Fehlversuche, Zwei-Faktor-Anmeldung, und keine Konten mit dem Namen admin.
2. Die Benutzerliste ist abrufbar. Unter /wp-json/wp/v2/users liefern viele Installationen die Anmeldenamen aller Autoren aus. Damit fehlt einem Angreifer nur noch das Passwort. Der Zugriff lässt sich einschränken.
3. Alte Plugins ohne Updates. Nicht nur veraltete — auch solche, die vom Entwickler gar nicht mehr gepflegt werden. Ein Plugin, dessen letzte Aktualisierung drei Jahre zurückliegt, bekommt auch bei einer bekannten Lücke keine Korrektur mehr.
4. Verzeichnisauflistung. Wenn /wp-content/uploads/ im Browser eine Dateiliste zeigt statt einer Fehlerseite, kann jeder sehen, was hochgeladen wurde — auch Dateien, die nirgends verlinkt sind.
5. XML-RPC. Die Schnittstelle /xmlrpc.php wird von den meisten Installationen nicht mehr gebraucht, taugt aber zum massenhaften Durchprobieren von Passwörtern in einer einzigen Anfrage. Wer sie nicht braucht, schaltet sie ab.

Alle fünf lassen sich an der eigenen Seite in fünf Minuten prüfen — vier davon durch bloßes Aufrufen der genannten Adressen.

Wo Selbstprüfung an ihre Grenze kommt

Das ist der ehrliche Teil. Alles bisher Beschriebene betrachtet die Außenhaut. Nicht gefunden werden dabei:

• Alles hinter der Anmeldung. Ob ein angemeldeter Kunde die Bestellungen anderer Kunden sehen kann, sieht man von außen nicht.
• Fehler in der Rechtevergabe. Der Klassiker: Eine Adresse wie /rechnung/1043 funktioniert auch mit einer fremden Nummer.
• Logikfehler im Ablauf. Rabattcodes, die sich mehrfach einlösen lassen; Bestellungen, bei denen sich der Preis manipulieren lässt.
• Schwache Passwörter von Mitarbeitern und fehlende Zwei-Faktor-Anmeldung.
• Der Zustand des Servers jenseits dessen, was er nach außen zeigt.
• Organisatorische Lücken — wer hat Zugriff, was passiert bei einem Ausfall, gibt es funktionierende Sicherungen.

Ein automatischer Scan — auch ein guter — hat dieselben Grenzen. Er misst zuverlässig und wiederholbar, was von außen sichtbar ist. Er ersetzt keinen Penetrationstest, bei dem jemand tatsächlich versucht, in das System zu kommen. Der Unterschied ist im Vergleich der Prüfarten ausführlicher beschrieben.

Wie oft man das machen sollte

Der häufigste Fall in der Praxis ist nicht, dass eine Website unsicher gebaut wurde, sondern dass sie unsicher geworden ist:

• Ein Zertifikat läuft ab, weil die automatische Erneuerung nach einem Serverumzug nicht mehr greift.
• Ein Plugin bekommt seit zwei Jahren keine Updates mehr, ohne dass es jemand merkt.
• Ein neues Marketingwerkzeug wird eingebaut und lädt Skripte aus einem Drittland.
• Ein Theme-Update setzt die lokal eingebundenen Schriften zurück auf Google.

Deshalb: nach jeder größeren Änderung prüfen, und ansonsten regelmäßig. Ein Termin im Kalender alle drei Monate deckt die meisten dieser Fälle ab — automatisierte Überwachung deckt sie am Tag ab, an dem sie entstehen.

Eine Reihenfolge zum Abarbeiten

1. Öffentlich erreichbare Dateien (Teil 4) — schwerwiegendster Fund, schnellste Prüfung.
2. Die vier Adressvarianten und das Zertifikat.
3. Fremde Dienste und Cookies vor der Einwilligung.
4. Veraltete Software aus den Kopfzeilen.
5. Sicherheitskopfzeilen ergänzen.
6. Tastaturbedienung und Barrierefreiheit.

Diese Reihenfolge folgt dem möglichen Schaden, nicht der Bequemlichkeit. Eine öffentlich erreichbare Datenbanksicherung wiegt schwerer als zehn fehlende Kopfzeilen.

Häufige Fragen

Kann ich meine Website ohne Fachwissen selbst prüfen?

Einen Teil davon ja. Verschlüsselung, Weiterleitungen, öffentlich erreichbare Dateien, veraltete Software und externe Dienste lassen sich mit Bordmitteln des Browsers und einigen kostenlosen Diensten prüfen. Was Fachwissen braucht, ist die Bewertung — also die Frage, wie schwer ein Befund wiegt und was zuerst drankommt.

Darf ich fremde Websites scannen?

Passives Betrachten dessen, was jeder Besucher ohnehin abruft, ist unproblematisch. Aktives Suchen nach Schwachstellen auf fremden Systemen ohne Auftrag ist es nicht — das kann strafbar sein. Prüfe nur, was dir gehört oder wofür du beauftragt bist.

Was findet ein automatischer Scan nicht?

Alles, was hinter einer Anmeldung liegt, Fehler in der Rechtevergabe, Logikfehler im Bestell- oder Buchungsablauf, schwache Passwörter und organisatorische Lücken. Ein Scan sieht die Außenhaut, nicht die Statik.

Wie oft sollte ich prüfen?

Nach jeder größeren Änderung und ansonsten regelmäßig. Der häufigste Fall ist nicht, dass eine Seite unsicher gebaut wurde, sondern dass sie unsicher geworden ist — durch ein abgelaufenes Zertifikat, eine veraltete Version oder ein neu eingebautes Werkzeug.

Reicht ein Sicherheits-Plugin?

Es hilft, ersetzt aber keine Prüfung von außen. Ein Plugin sieht die Seite von innen und kann nicht beurteilen, was ein Besucher tatsächlich geliefert bekommt — etwa welche Kopfzeilen ankommen oder welche Dateien öffentlich erreichbar sind.

Ist es schlimm, wenn der Server seine Version verrät?

Für sich genommen nein — die Version zu verbergen ist keine Sicherheit. Es nimmt aber Gelegenheitssuchern die Vorarbeit, und es ist ein Hinweis darauf, dass an der Konfiguration nie jemand gearbeitet hat. Wichtiger als das Verbergen ist, dass die Version aktuell ist.

Stand: 6. August 2026. Dieser Text erklärt technische Zusammenhänge und ist keine Rechtsberatung.