Website-Check

Was der Website-Check prüft

• Webserver und PHP: aus den Antwort-Headern Server und X-Powered-By. Verrät der Server seine PHP-Version, zeigt das Werkzeug auch, wie lange es dafür noch Sicherheitsupdates gibt.
• CMS, Shop und Plugins: WordPress, TYPO3, Joomla, Drupal, Contao, Shopware, Magento, JTL, Shopify, Wix und weitere, erkannt an Generator-Angaben, typischen Pfaden, Cookies und Headern. Bei WordPress auch Seitenbaukästen, SEO- und Cache-Plugins.
• Externe Quellen: alles, was der Browser beim Aufruf von fremden Servern holt, also Schriften, Skripte, Videos, Karten, Bilder und Widgets. Zusätzlich durchsucht das Werkzeug bis zu sechs eigene Stylesheets nach eingebundenen Google Fonts.
• Security-Header: HSTS, Content-Security-Policy, X-Content-Type-Options, Schutz gegen Clickjacking, Referrer-Policy und Permissions-Policy.
• HTTPS und Zertifikat: Weiterleitungskette, Umleitung von HTTP auf HTTPS, Aussteller, Laufzeit, Namen im Zertifikat und TLS-Version.
• SEO-Grundlagen: Title, Meta Description, Robots-Angaben, Canonical, Sprache und H1.

Externe Quellen und die Frage nach der Zustimmung

Jede Datei, die eine Website von einem fremden Server lädt, schickt dabei die IP-Adresse des Besuchers an diesen Anbieter. Das bekannteste Beispiel sind Google Fonts: Das Landgericht München I hat 2022 entschieden, dass die Einbindung direkt von Google ohne Einwilligung gegen die DSGVO verstößt (Az. 3 O 17493/20). Danach folgte eine Welle von Abmahnschreiben. Für Statistik- und Werbedienste gilt ohnehin: Sie dürfen erst nach Zustimmung laden.

Das Werkzeug unterscheidet deshalb, wie eine Quelle eingebunden ist:

• lädt sofort: als Skript, Stylesheet, Bild oder iframe direkt im HTML. Der Browser holt es, bevor der Besucher etwas anklicken kann.
• per Skript nachgeladen: ein Skript auf der Seite enthält die Adresse, typisch für den Google Tag Manager. Ob es vorher auf eine Zustimmung wartet, hängt von der Einrichtung ab.
• Verbindung vorab: preconnect baut schon eine Verbindung auf, die IP-Adresse geht dabei an den Anbieter.
• wartet auf Zustimmung: als blockiertes Skript (type="text/plain") oder als Platzhalter mit data-src. So arbeiten Consent-Tools wie Borlabs, Complianz, Cookiebot oder Usercentrics.

Grenzen einer statischen Prüfung

Der Website-Check ruft die Seite so ab wie ein Suchmaschinen-Crawler und wertet das ausgelieferte HTML aus. Er führt kein JavaScript aus. Alles, was erst ein Skript nachlädt, bleibt deshalb unsichtbar: Tags aus dem Google Tag Manager, Widgets, die sich selbst einbauen, oder Inhalte von Single-Page-Apps. Ein Ergebnis „keine externen Quellen“ heißt also: im HTML nichts gefunden. Für den vollständigen Blick braucht es einen echten Browser, zum Beispiel die Netzwerk-Ansicht der Entwicklerwerkzeuge (F12, Reiter „Netzwerk“) in einem privaten Fenster ohne Zustimmung.

Manche Seiten sperren automatisierte Abrufe oder zeigen erst eine Captcha-Seite. Das erkennt das Werkzeug und weist darauf hin, die Analyse ist dann nur teilweise aussagekräftig.

Versionen verstecken: weniger Angriffsfläche

Ein Header wie Server: Apache/2.4.41 (Ubuntu) oder X-Powered-By: PHP/8.1.2 hilft niemandem außer Angreifern, die gezielt nach bekannten Lücken einer Version suchen. Die Versionen auszublenden, ersetzt keine Updates, kostet aber nur eine Zeile:

# PHP (php.ini oder in Plesk: PHP-Einstellungen, zusätzliche Direktiven)
expose_php = Off

# nginx (http-Block)
server_tokens off;

# Apache (z. B. /etc/apache2/conf-available/security.conf)
ServerTokens Prod
ServerSignature Off

Prüfen lässt sich das Ergebnis in der Shell mit dem Einzeiler Webserver und PHP-Version im HTTP-Header erkennen.

Security-Header nachrüsten

Die meisten Header lassen sich mit wenigen Zeilen setzen, in Plesk unter „Apache- und nginx-Einstellungen“ bei den zusätzlichen nginx-Direktiven. Ein solider Start, der kaum etwas kaputt macht:

add_header Strict-Transport-Security "max-age=31536000" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Die Content-Security-Policy ist mächtiger, aber auch heikler: Eine zu strenge Regel blockiert eigene Skripte, Formulare oder das Consent-Tool. Am besten zuerst als Content-Security-Policy-Report-Only testen. Ob HSTS wirkt, zeigt der Einzeiler Prüfen, ob eine Website den HSTS-Header sendet.

Weitere Einzeiler für den Website-Check in der Shell

• Ablaufdatum des SSL-Zertifikats einer Website prüfen
• Weiterleitungskette einer URL mit Statuscodes anzeigen
• Mixed Content im HTML einer HTTPS-Seite finden
• WordPress-Core aktualisieren inklusive Datenbank
• PHP-Version der Kommandozeile anzeigen

Datenschutz

Die Prüfung läuft auf dem Server von myline.de. Er ruft die eingegebene Seite ab, so wie es jeder Browser tut, und gibt sich dabei offen als „myline-website-check“ zu erkennen. Deine IP-Adresse geht nicht an die geprüfte Seite, eingegebene Adressen und Ergebnisse werden nicht gespeichert. Gegen Missbrauch gilt ein Limit von 20 Prüfungen pro Stunde, dafür wird kurzzeitig nur ein verschlüsselter Prüfwert gehalten, keine IP-Adresse. Interne Netze und andere Ports als 80 und 443 ruft das Werkzeug grundsätzlich nicht ab.

Standortdaten: IP Geolocation by DB-IP, Lizenz CC BY 4.0.