{"id":5742,"date":"2026-11-04T23:04:07","date_gmt":"2026-11-04T22:04:07","guid":{"rendered":"https:\/\/wwwschutz.de\/blog\/?p=5742"},"modified":"2026-10-23T16:11:16","modified_gmt":"2026-10-23T14:11:16","slug":"website-angreifersicht-erste-60-sekunden","status":"publish","type":"post","link":"https:\/\/wwwschutz.de\/blog\/website-angreifersicht-erste-60-sekunden\/","title":{"rendered":"Website aus Angreifersicht: Was in 60 Sekunden sichtbar ist"},"content":{"rendered":"\n

Wer eine Website angreifen will, beginnt mit Beobachten. Server-Header, Quelltext, Standardpfade und Zertifikate verraten oft in einer Minute, womit eine Seite arbeitet. Der Beitrag zeigt die Website aus Angreifersicht an der eigenen Seite, ordnet ein, was blo\u00df Information und was ein echtes Risiko ist, und beschreibt eine Selbstpr\u00fcfung mit Bordmitteln.<\/em><\/p>\n\n\n\n

Die meisten Betreiber kennen ihre Website von innen: Das Backend, die Plugins, die Einstellungen. Von au\u00dfen sieht die Seite anders aus. Dort gibt es keine Anmeldung und keine Rechte, nur das, was jeder Browser und jedes Skript abrufen kann. Genau diese Au\u00dfensicht ist der Ausgangspunkt f\u00fcr automatisierte Scans und f\u00fcr gezielte Vorbereitung.<\/p>\n\n\n\n

Der Beitrag geht die erste Minute dieser Au\u00dfensicht in f\u00fcnf Etappen durch. Er betrachtet ausschlie\u00dflich \u00f6ffentlich abrufbare Informationen und Pr\u00fcfungen an der eigenen Website. Er enth\u00e4lt keine Anleitung zum Ausnutzen von L\u00fccken und keine Aufforderung, fremde Systeme zu untersuchen. Aktive Scans fremder Systeme ohne Erlaubnis k\u00f6nnen strafbar sein und sind deshalb tabu. Der Text ist keine Rechtsberatung. Am Ende stehen eine Gewichtung der Funde, eine Selbstpr\u00fcfung und eine Checkliste.<\/p>\n\n\n\n

Die eigene Website aus Angreifersicht: Warum der Blick von au\u00dfen z\u00e4hlt<\/h2>\n\n\n\n

Angriffe beginnen selten mit einem Angriff. Am Anfang steht die Aufkl\u00e4rung: Welche Software l\u00e4uft, in welcher Version, welche Pfade gibt es, was liegt dort wom\u00f6glich herum? Diese Phase nennt sich Informationsgewinnung. Das Open Worldwide Application Security Project (OWASP) f\u00fchrt sie in seinem Web Security Testing Guide<\/a> als eigene Testphase auf, noch vor allen Pr\u00fcfungen auf konkrete Schwachstellen. Die Website aus Angreifersicht zu betrachten hei\u00dft also: dieselben ersten Schritte nachzuvollziehen.<\/p>\n\n\n\n

Dabei ist kein pers\u00f6nliches Interesse n\u00f6tig. Ein gro\u00dfer Teil der Zugriffe auf jede \u00f6ffentliche Seite stammt von automatisierten Programmen. Sie arbeiten Adresslisten ab, lesen Header und Quelltext und gleichen das Ergebnis mit bekannten Schwachstellen ab. Eine kleine Firmenseite steht in derselben Liste wie ein Konzernauftritt. Wer sich fragt, wer ausgerechnet die eigene Seite anschauen sollte, \u00fcbersieht, dass hier niemand etwas anschaut. Es l\u00e4uft ein Abgleich.<\/p>\n\n\n\n

Wichtig ist die Unterscheidung zwischen Information und Schwachstelle. Eine Information ist etwa die Angabe, dass ein Webserver in einer bestimmten Version l\u00e4uft. Eine Schwachstelle ist eine ausnutzbare L\u00fccke. Die Information ist noch keine L\u00fccke, sie hilft nur dabei, passende L\u00fccken zu finden. Dieser Unterschied zieht sich durch den ganzen Beitrag. Informationspreisgabe ist ein Risikoverst\u00e4rker, kein Einbruch.<\/p>\n\n\n\n

Die folgende \u00dcbersicht fasst die f\u00fcnf Etappen zusammen, die in den n\u00e4chsten Abschnitten einzeln behandelt werden. Die Zeitangaben sind ein Gedankenmodell. In der Praxis laufen die Schritte automatisiert und parallel, sie dauern eher Sekundenbruchteile.<\/p>\n\n\n\n

\"Zeitachse
F\u00fcnf Etappen der Au\u00dfensicht in den ersten 60 Sekunden.<\/figcaption><\/figure>\n\n\n\n

Sekunde 0 bis 10: Was die HTTP-Antwort verr\u00e4t<\/h2>\n\n\n\n

Schon der erste Abruf der Startseite liefert neben dem Inhalt eine Reihe von Kopfzeilen, die Header. Sie sind f\u00fcr den Browser gedacht, aber jeder kann sie lesen. Typisch ist der Server<\/code>-Header. Er nennt h\u00e4ufig den Webserver, dessen Version und manchmal das Betriebssystem. Dazu kommt oft X-Powered-By<\/code> mit der PHP-Version. Auch Cookie-Namen verraten viel: Ein Cookie mit dem Pr\u00e4fix wordpress_<\/code> macht das eingesetzte System sofort erkennbar.<\/p>\n\n\n\n

Das Auslesen dieser Angaben hei\u00dft Banner Grabbing. Der OWASP-Leitfaden zum Fingerprinting von Webservern<\/a> (WSTG-INFO-02) beschreibt den Zweck so: Typ und Version des Servers bestimmen, um zu pr\u00fcfen, ob bekannte Schwachstellen f\u00fcr diese Version vorliegen. Veraltete Server ohne aktuelle Korrekturen sind daf\u00fcr besonders anf\u00e4llig. Zugleich weist der Leitfaden darauf hin, dass sich solche Header \u00e4ndern oder verschleiern lassen.<\/p>\n\n\n\n

Auch fehlende Angaben sagen etwas aus. Wer die Header f\u00fcr den Transportschutz (HSTS) oder f\u00fcr eine Inhaltsrichtlinie (CSP) nicht setzt, zeigt, dass an der Konfiguration lange nichts getan wurde. Das ist kein Beweis f\u00fcr eine L\u00fccke, aber ein Hinweis auf den Reifegrad. Weiterleitungen von HTTP auf HTTPS, Fehlerseiten und die Reihenfolge der Header sind weitere Spuren.<\/p>\n\n\n\n

\"Website
Beispiel einer HTTP-Antwort mit erfundenen Werten und ihrer Lesart von au\u00dfen.<\/figcaption><\/figure>\n\n\n\n

Soll die Version nicht mehr im Header stehen, l\u00e4sst sich das bei Apache einstellen. Laut Apache-Dokumentation<\/a> steuert die Direktive ServerTokens<\/code>, wie viel der Server<\/code>-Header preisgibt. Standardwert ist Full<\/code> mit Version, Betriebssystem und Modulen. Mit ServerTokens Prod<\/code> bleibt nur Server: Apache<\/code> \u00fcbrig. Die Direktive ServerSignature<\/code> regelt die Fu\u00dfzeile auf vom Server erzeugten Seiten, etwa Fehlerseiten. Ihr Standardwert ist Off<\/code>. Bei nginx \u00fcbernimmt server_tokens off<\/code> eine \u00e4hnliche Aufgabe. Bei PHP l\u00e4sst sich expose_php<\/code> abschalten, damit X-Powered-By<\/code> entf\u00e4llt. Wer die Server-Version verbergen will, findet die Einstellung also in der Regel in einer einzigen Zeile der Konfiguration.<\/p>\n\n\n\n

Ehrlich bleibt das nur mit einem Zusatz: Das Verbergen ist keine Sicherheit, sondern bestenfalls Verz\u00f6gerung. Verhalten und Fehlerseiten eines Servers lassen sich weiterhin einordnen, wie auch der OWASP-Leitfaden festh\u00e4lt. Wichtiger als ein versteckter Header ist ein Server, der ohnehin aktuell ist.<\/p>\n\n\n\n

Sekunde 10 bis 25: Quelltext, Plugin-Liste und Theme-Hinweise<\/h2>\n\n\n\n

Der Quelltext einer Seite ist \u00f6ffentlich. Bei WordPress stehen darin die Adressen aller eingebundenen Skripte und Stylesheets. Diese Adressen enthalten die Pfade wp-content\/plugins<\/code> und wp-content\/themes<\/code> samt Ordnernamen. Daraus ergibt sich ohne jede Anmeldung eine Liste der aktiven Plugins und des Themes. Oft h\u00e4ngt am Ende der Adresse ein Versionsparameter wie ?ver=<\/code>. Auch das Generator-Meta-Tag nennt gelegentlich die WordPress-Version. Wer wissen will, wie leicht sich eine WordPress-Plugin-Version auslesen l\u00e4sst, muss nur den eigenen Quelltext durchsuchen.<\/p>\n\n\n\n

Erg\u00e4nzend k\u00f6nnen Dateien im Plugin-Ordner selbst Versionen nennen, zum Beispiel eine mitgelieferte readme.txt<\/code>. Dazu kommen Kommentare im Quelltext, Pfade aus der Entwicklungsumgebung und Hinweise auf Werkzeuge, mit denen die Seite gebaut wurde. Nichts davon ist f\u00fcr sich gef\u00e4hrlich. Zusammen ergibt es aber ein ziemlich genaues Bild der technischen Grundlage.<\/p>\n\n\n\n

Der n\u00e4chste Schritt ist ein Abgleich mit \u00f6ffentlichen Schwachstellendatenbanken. Dort sind bekannte L\u00fccken nach Produkt und Version aufgelistet, und zwar ausdr\u00fccklich, damit Betreiber ihre Seiten sch\u00fctzen k\u00f6nnen. Automatisierte Programme nutzen dieselben Daten. Ein Plugin, das seit Monaten kein Update erhalten hat und in der Liste auftaucht, ist damit auffindbar, ohne dass jemand die Seite je besucht h\u00e4tte.<\/p>\n\n\n\n

Eine Versionsnummer im Header ist noch keine Schwachstelle. Sie macht nur sichtbar, ob eine bekannte L\u00fccke offen sein k\u00f6nnte.<\/p><\/blockquote><\/figure>\n\n\n\n

Der Quelltext verr\u00e4t noch etwas anderes: Welche Drittdienste eingebunden sind. Tracking-Skripte, eingebettete Videos, externe Schriften und Karten tauchen als Adressen auf fremden Servern auf. F\u00fcr die Sicherheit ist das nebens\u00e4chlich. F\u00fcr den Datenschutz ist es ein Nebenbefund, denn jeder dieser Dienste erh\u00e4lt die IP-Adresse der Besucher. Ein Blick auf die Liste lohnt deshalb doppelt.<\/p>\n\n\n\n

Eine Konsequenz ist deutlich: Plugins und Themes, die nicht gebraucht werden, geh\u00f6ren entfernt und nicht nur deaktiviert. Das Hardening-Kapitel der WordPress-Entwicklerdokumentation<\/a> empfiehlt ebenfalls, Software aktuell zu halten und Unbenutztes zu l\u00f6schen. Was nicht installiert ist, kann nicht veralten.<\/p>\n\n\n\n

Sekunde 25 bis 40: Offene Verzeichnisse, Standardpfade und vergessene Dateien<\/h2>\n\n\n\n

Nach dem Quelltext folgen Pfade, die sich ohne Verlinkung erraten lassen. Bei WordPress sind das etwa \/wp-admin<\/code>, \/wp-login.php<\/code> und \/wp-json<\/code>. Diese Pfade sind \u00fcberall gleich und \u00fcberall dokumentiert. Dass sie existieren, ist normal und kein Befund. Interessant wird es, wenn sich dahinter mehr zeigt als vorgesehen.<\/p>\n\n\n\n

Das erste Beispiel ist das Verzeichnislisting. Fehlt in einem Ordner eine Startdatei und ist die Auflistung erlaubt, erzeugt der Server eine Dateiliste. Die Apache-Dokumentation beschreibt das so: Wird eine Adresse angefragt, die auf ein Verzeichnis zeigt, und liegt dort kein DirectoryIndex<\/code> wie index.html<\/code>, liefert mod_autoindex<\/code> eine formatierte Auflistung. Bei offenen Verzeichnissen kann jeder sehen, welche Dateien dort liegen, etwa im Upload-Ordner. Das Verzeichnislisting l\u00e4sst sich per Apache-Direktive Options -Indexes<\/code> deaktivieren, bei nginx gen\u00fcgt es, autoindex<\/code> nicht zu aktivieren.<\/p>\n\n\n\n

Das zweite Beispiel sind vergessene Dateien. Beim Umbau oder Umzug einer Website bleiben gern Dinge liegen: ein Datenbank-Export, ein Archiv mit der alten Seite, eine Sicherungskopie der Konfiguration, ein Ordner der Versionsverwaltung, eine Datei mit Zugangsdaten, eine Testseite mit Systeminformationen. Die Dateiendungen und Namen sind so \u00fcblich, dass Skripte sie als Liste abfragen. Wer eine solche Datei auf dem eigenen Server nicht kennt, sollte sie finden, bevor es jemand anders tut.<\/p>\n\n\n\n

Warum das mehr als ein Sch\u00f6nheitsfehler ist, liegt auf der Hand. Datenbank-Exporte enthalten Kundendaten, Konfigurationsdateien Zugangsdaten. Wer solche Dateien frei abrufbar l\u00e4sst, macht aus einem Verwaltungsfehler eine Datenpanne. Die DSGVO verlangt in Artikel 32<\/a> technische und organisatorische Ma\u00dfnahmen, die dem Risiko angemessen sind. Offen herumliegende Exporte widersprechen dem, ohne dass es daf\u00fcr eine Angriffsleistung brauchte. Weiterf\u00fchrend zum Personenbezug solcher Datens\u00e4tze behandelt der Beitrag zu personenbeziehbaren Daten<\/em> die Frage, wann Daten als personenbezogen gelten.<\/p>\n\n\n\n

Die Gegenma\u00dfnahmen sind unspektakul\u00e4r. Sicherungen und Exporte geh\u00f6ren au\u00dferhalb des \u00f6ffentlich erreichbaren Verzeichnisses (Webroot) oder zumindest hinter eine Zugriffssperre. Die Dateirechte sollten nicht gro\u00dfz\u00fcgiger sein als n\u00f6tig. Die WordPress-Dokumentation nennt f\u00fcr Verzeichnisse 755 und f\u00fcr Dateien 644, f\u00fcr wp-config.php<\/code> 400 oder 440. Debug-Ausgaben geh\u00f6ren im Livebetrieb abgeschaltet, ebenso Testskripte mit Systemangaben.<\/p>\n\n\n\n

Sekunde 40 bis 50: Metadateien, Nutzernamen und Schnittstellen<\/h2>\n\n\n\n

Metadateien sind f\u00fcr Suchmaschinen und Programme gedacht. Die bekannteste ist die robots.txt<\/code>. Sie sagt Crawlern, was sie nicht abrufen sollen. Genau darin liegt ein Missverst\u00e4ndnis. Der OWASP-Leitfaden zu Metadateien<\/a> (WSTG-INFO-03) stellt klar, dass die robots.txt<\/code> nicht als Mechanismus zur Durchsetzung von Beschr\u00e4nkungen gelten sollte. Wer dort einen internen Pfad ausschlie\u00dft, nennt ihn zugleich jedem, der die Datei liest. Ein Pfad geh\u00f6rt also nicht in die robots.txt<\/code>, wenn er geheim bleiben soll, sondern hinter eine Anmeldung. \u00c4hnlich verh\u00e4lt es sich mit der Sitemap: Sie ist eine bewusste Liste der Seiten und sollte nichts enthalten, was nicht \u00f6ffentlich sein soll.<\/p>\n\n\n\n

Dann die Benutzernamen. G\u00fcltige Benutzernamen sind f\u00fcr Angriffe auf Anmeldungen n\u00fctzlich, denn dann fehlt nur noch das Passwort. Mehrere Quellen kommen infrage: Autoren-Archive, die den Anmeldenamen in der Adresse tragen, Fehlermeldungen beim Login, die zwischen falschem Namen und falschem Passwort unterscheiden, und die REST-Schnittstelle. Laut REST-Referenz zu Nutzern<\/a> liefert die Abfrage von Nutzern im Kontext view<\/code> Felder wie Anzeigename, Kurzname (slug), Link und Beschreibung. Felder wie E-Mail-Adresse und Rollen sind dem Kontext edit<\/code> vorbehalten. Ob und welche Nutzer unangemeldet erscheinen, steht dort nicht eindeutig. Das Verhalten h\u00e4ngt von der WordPress-Version und der Konfiguration ab und l\u00e4sst sich am schnellsten an der eigenen Seite pr\u00fcfen: Ruft der Browser die Nutzer-Schnittstelle unter \/wp-json\/wp\/v2\/users<\/code> der eigenen Domain ab, zeigt sich, was ohne Anmeldung ausgegeben wird. Der Kurzname entspricht nicht automatisch dem Anmeldenamen, kann ihm aber \u00e4hneln.<\/p>\n\n\n\n

Als sinnvolle Gegenma\u00dfnahmen kommen einheitliche Fehlermeldungen beim Login, sparsam vergebene Autorenkonten, Anzeigenamen, die vom Anmeldenamen abweichen, und starke Passw\u00f6rter mit einem zweiten Faktor infrage. Ein verborgener Benutzername ist ebenfalls nur eine H\u00fcrde. Die eigentliche Absicherung ist, dass ein bekannter Name allein nichts n\u00fctzt.<\/p>\n\n\n\n

Die security.txt<\/code> ist das Gegenbeispiel: eine Metadatei, die ausdr\u00fccklich gefunden werden soll. RFC 9116<\/a> beschreibt sie als Datei unter \/.well-known\/security.txt<\/code> mit den Pflichtfeldern Contact<\/code> und Expires<\/code>. Wer eine Schwachstelle findet, erf\u00e4hrt dort, wohin die Meldung gehen soll. Das ist die kontrollierte Variante von Sichtbarkeit.<\/p>\n\n\n\n

Sekunde 50 bis 60: Domain, Zertifikat und Suchmaschinen<\/h2>\n\n\n\n

Die letzte Etappe verl\u00e4sst die Seite selbst. Zertifikate f\u00fcr HTTPS werden in \u00f6ffentlichen Protokollen vermerkt, der sogenannten Zertifikatstransparenz. Das Verfahren ist in RFC 6962<\/a> beschrieben, die Nachfolgeversion tr\u00e4gt die Nummer 9162. Der Zweck ist, falsch ausgestellte Zertifikate sichtbar zu machen. Als Nebenwirkung steht in diesen Protokollen jeder Hostname, f\u00fcr den ein Zertifikat ausgestellt wurde. Wer f\u00fcr test<\/code>, staging<\/code> oder intranet<\/code> unter der eigenen Domain ein Zertifikat beantragt, tr\u00e4gt diesen Namen damit \u00f6ffentlich ein.<\/p>\n\n\n\n

Hinzu kommen die DNS-Eintr\u00e4ge der Domain. Sie zeigen Mailserver, Subdomains und Dienste. Und schlie\u00dflich der Suchmaschinen-Index: Eine Suche mit site:<\/code> und der eigenen Domain listet auf, was Suchmaschinen kennen. Dazu k\u00f6nnen PDF-Dateien, Testseiten, Exportdateien und alte Seitenversionen geh\u00f6ren, die nie jemand finden sollte.<\/p>\n\n\n\n

Besonders anf\u00e4llig sind Staging-Systeme. Das sind Kopien der Seite zum Testen. Sie laufen oft mit \u00e4lterer Software, schw\u00e4cheren Passw\u00f6rtern oder abgeschalteter Absicherung, enthalten aber nicht selten echte Daten. Wird ein Staging-System nicht mit einem Passwortschutz versehen, kann es in Suchmaschinen landen. F\u00fcr diese Etappe gilt wie f\u00fcr alle anderen: Es werden nur \u00f6ffentlich zug\u00e4ngliche Quellen genutzt, und nur f\u00fcr die eigene Domain. Das Durchsuchen fremder Systeme ist keine Pr\u00fcfung, sondern ein Eingriff.<\/p>\n\n\n\n

Was aus den Funden folgt: Information, Risiko, Aufwand<\/h2>\n\n\n\n

Nach den f\u00fcnf Etappen stellt sich die Frage der Gewichtung. Nicht jede sichtbare Angabe verlangt sofortiges Handeln. Eine Seite ohne sichtbare Spuren gibt es nicht. Die Frage lautet, was ein Fund f\u00fcr sich bedeutet, und was erst in Kombination gef\u00e4hrlich wird. Die Tabelle ordnet die h\u00e4ufigsten Funde ein.<\/p>\n\n\n\n

\n\n
Fund<\/th>Was ein Angreifer daraus macht<\/th>Gegenma\u00dfnahme<\/th>Dringlichkeit<\/th><\/tr><\/thead>\n
Server- und PHP-Version im Header<\/td>Abgleich mit bekannten L\u00fccken dieser Version<\/td>Updates einspielen, Version im Header ausblenden<\/td>Mittel<\/td><\/tr>\n
Plugin-Liste mit Versionen im Quelltext<\/td>Suche nach veralteten Plugins mit bekannten L\u00fccken<\/td>Aktualisieren, Unbenutztes entfernen<\/td>Hoch bei veralteten Plugins<\/td><\/tr>\n
Offenes Verzeichnislisting<\/td>Dateiliste durchsehen, interessante Dateien abrufen<\/td>Auflistung abschalten, Inhalte pr\u00fcfen<\/td>Mittel bis hoch<\/td><\/tr>\n
Backup oder Datenbank-Export abrufbar<\/td>Zugangsdaten und personenbezogene Daten auslesen<\/td>Entfernen, au\u00dferhalb des Webroots speichern, Zugangsdaten \u00e4ndern<\/td>Sehr hoch, sofort<\/td><\/tr>\n
Benutzernamen sichtbar<\/td>Gezielte Anmeldeversuche<\/td>Starke Passw\u00f6rter, zweiter Faktor, einheitliche Fehlermeldungen<\/td>Mittel<\/td><\/tr>\n
Staging-System erreichbar<\/td>Schw\u00e4cher gesch\u00fctzte Kopie der Seite angreifen<\/td>Passwortschutz, Abschalten, Index pr\u00fcfen<\/td>Hoch<\/td><\/tr>\n
robots.txt mit internen Pfaden<\/td>Pfade als Wegweiser nutzen<\/td>Pfade nicht auff\u00fchren, hinter Anmeldung legen<\/td>Niedrig<\/td><\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n

Wer Versionsnummern versteckt, gewinnt Zeit. Wer aktualisiert, gewinnt Sicherheit.<\/p><\/blockquote><\/figure>\n\n\n\n

Dieser Satz fasst die wichtigste Erkenntnis zusammen. Das Verbergen der Version ist ein Handgriff von wenigen Minuten und senkt das Rauschen, es ersetzt aber keine Aktualisierung. Fingerprinting erkennt Server h\u00e4ufig auch ohne Banner. Wer sich auf das Verstecken verl\u00e4sst, praktiziert Security through Obscurity, also Sicherheit durch Geheimhaltung der Technik. Die Verfahren bleiben sinnvoll als zus\u00e4tzliche Schicht, nicht als Ersatz.<\/p>\n\n\n\n

Nach Aufwand sortiert ergibt sich eine einfache Reihenfolge. Zuerst kommen die Dinge, die schnell gehen und viel bringen: Updates f\u00fcr Kern, Plugins und Themes, ungenutzte Erweiterungen entfernen, offene Backups und Exporte wegnehmen. Danach folgen Verzeichnislisting abschalten, Dateirechte pr\u00fcfen, Debug-Ausgaben ausschalten und Staging-Systeme absichern. Zum Schluss kommen die Feinarbeiten: Header minimieren, Sicherheits-Header erg\u00e4nzen und eine security.txt<\/code> bereitstellen. Wer so vorgeht, verkleinert die Angriffsfl\u00e4che der Website dort am st\u00e4rksten, wo es z\u00e4hlt.<\/p>\n\n\n\n

Die zentrale Frage dieses Beitrags l\u00e4sst sich nach den f\u00fcnf Etappen so beantworten:<\/p>\n\n\n

\n
\n

Was sieht ein Angreifer von au\u00dfen auf einer Website, ohne sich anzumelden?<\/h4>\n
\n
Ohne Anmeldung lassen sich oft Webserver-Typ und Version aus den HTTP-Headern, eingesetzte Plugins samt Versionen aus dem Quelltext, offene Verzeichnisse, Standardpfade, Hinweise in der robots.txt und teilweise Benutzernamen ablesen. Das sind zun\u00e4chst nur Informationen, noch keine Schwachstellen. Gef\u00e4hrlich werden sie, wenn eine Version mit einer bekannten L\u00fccke zusammentrifft. Wirksamer als das Verbergen von Versionsnummern sind zeitnahe Updates, das Entfernen ungenutzter Plugins und abgeschaltetes Verzeichnislisting.<\/div>\n <\/div>\n <\/div>\n\n <\/div>\n \n\n\n\n

Selbstpr\u00fcfung der eigenen Website: Schritt f\u00fcr Schritt mit Bordmitteln<\/h2>\n\n\n\n

F\u00fcr die erste Bestandsaufnahme gen\u00fcgt ein Browser. Wichtig ist der Rahmen: Gepr\u00fcft wird ausschlie\u00dflich die eigene Website, oder eine, f\u00fcr die eine ausdr\u00fcckliche Erlaubnis vorliegt. Fremde Seiten sind tabu, auch aus Neugier.<\/p>\n\n\n\n

Der erste Schritt sind die Header. In den Entwicklerwerkzeugen des Browsers zeigt der Reiter Netzwerk beim Laden der Seite die Antwort-Header des ersten Abrufs. Wer die Kommandozeile bevorzugt, bekommt dasselbe mit curl -I https:\/\/domain.example\/<\/code>, wobei die Beispieladresse durch die eigene Domain zu ersetzen ist. Notiert werden Server<\/code>, X-Powered-By<\/code>, Cookies und vorhandene Sicherheits-Header.<\/p>\n\n\n\n

Der zweite Schritt ist der Quelltext. Die Ansicht des Seitenquelltexts l\u00e4sst sich mit der Suche nach wp-content<\/code>, ?ver=<\/code>, generator<\/code> und nach Kommentaren durchgehen. Das ergibt die Plugin- und Theme-Liste, wie sie auch von au\u00dfen zu sehen ist. Danach folgt der Abgleich mit dem Backend: Gibt es dort Erweiterungen, die nicht mehr gebraucht werden?<\/p>\n\n\n\n

Der dritte Schritt betrifft Verzeichnisse. WordPress-Ratgeber empfehlen, Ordner wie \/wp-content\/uploads\/<\/code> oder \/wp-includes\/<\/code> der eigenen Seite im Browser aufzurufen. Erscheint eine Dateiliste statt einer Fehlermeldung oder leeren Seite, ist das Verzeichnislisting aktiv. Der vierte Schritt sucht von Hand nach Dateien, die nicht \u00f6ffentlich sein sollen: Exporte, Archive, Konfigurationskopien, Testseiten. Am zuverl\u00e4ssigsten gelingt das nicht \u00fcber Raten von au\u00dfen, sondern \u00fcber einen Blick ins Dateisystem des eigenen Servers. Was dort im \u00f6ffentlichen Ordner liegt, ist auch von au\u00dfen erreichbar.<\/p>\n\n\n\n

Der f\u00fcnfte Schritt gilt den Nutzerangaben. Der Aufruf der REST-Nutzerliste, die Adresse eines Autoren-Archivs und eine absichtlich falsche Anmeldung zeigen, was die Seite preisgibt. Im sechsten Schritt wird mit site:<\/code> und der eigenen Domain bei einer Suchmaschine gepr\u00fcft, was im Index steht. Der siebte Schritt betrifft Staging- und Testsysteme: Sind sie erreichbar, gesch\u00fctzt und aus dem Index ferngehalten? Die Abbildung fasst die Schritte als Checkliste zusammen.<\/p>\n\n\n\n

\"Checkliste
Sieben Schritte zur Selbstpr\u00fcfung der eigenen Website.<\/figcaption><\/figure>\n\n\n\n

Manuelle Pr\u00fcfung hat Grenzen. Sie ist langsam und h\u00e4ngt davon ab, dass die richtigen Stellen angesehen werden. Erg\u00e4nzend kommen automatisierte Auswertungen infrage. Der Webseiten-Check von Dr. DSGVO<\/a> betrachtet eine Seite aus datenschutzrechtlicher Sicht, etwa Drittdienste und Cookies. F\u00fcr technische Aspekte wie Header, Versionsangaben und Standardpfade sind die Security-Checks von wwwschutz.de<\/a> eine m\u00f6gliche Erg\u00e4nzung. Beides ersetzt kein Gespr\u00e4ch mit dem Hoster oder der Agentur, hilft aber dabei, das Bild zu vervollst\u00e4ndigen. Und wer beim Netzwerk-Panel ohnehin sitzt, kann dort zugleich nachsehen, welche Anfragen die Seite beim Laden ausl\u00f6st, wie es der Beitrag zu Speculation Rules und Datenschutz<\/em> f\u00fcr das Vorab-Laden zeigt.<\/p>\n\n\n\n

Fazit: Sichtbarkeit begrenzen, Aktualit\u00e4t sichern<\/h2>\n\n\n\n

Die erste Minute der Au\u00dfensicht zeigt vor allem eines: Eine Website verr\u00e4t mehr, als ihre Betreiber ahnen. Das ist normal und l\u00e4sst sich nicht vollst\u00e4ndig verhindern. Es l\u00e4sst sich aber begrenzen und, wichtiger, entsch\u00e4rfen.<\/p>\n\n\n\n