Ein passiver externer Scan. Jeder Befund enthält die Rohbeobachtung des Scanners
und einen Befehl, den Sie selbst ausführen können, um ihn zu reproduzieren - nichts hier wurde von einem Modell geschrieben.
14 Prüfgruppen:
DNS auflösen und CAA prüfen · SPF und DMARC prüfen · TLS-Zertifikat und Protokollversionen prüfen · HTTP-zu-HTTPS-Weiterleitung testen · Sicherheits-Header der Antwort auslesen · Cookie-Attribute prüfen · CORS-Richtlinie untersuchen · Nach Versions-Bannern suchen · Erlaubte HTTP-Methoden prüfen · Startseite auf gemischte Inhalte und unsichere Formulare prüfen · Nach offengelegten Konfigurations- und Versionsverwaltungsdateien suchen · Auf Verzeichnislisten prüfen · robots.txt und security.txt auslesen · Auf offengelegte Dienst-Ports prüfen
Startet…
0%
Über Website-Sicherheitsscan
Viele Scanner geben Ihnen eine Schulnote und eine Liste beängstigender Begriffe. Dieser vergibt ebenfalls eine Note, aber jeder abgezogene Punkt hängt an einem Befund, der die tatsächlich erhaltene Antwort zeigt und den Einzeiler-Befehl, mit dem Sie dieselbe Antwort bekommen. Ein Befund ist also etwas, das Sie prüfen können, nicht etwas, das Sie glauben müssen.
Was es tut
Prüft DNS und CAA, SPF und DMARC, das TLS-Zertifikat und TLS 1.0/1.1, die HTTPS-Weiterleitung, Sicherheits-Header, Cookie-Attribute, CORS, Versionsbanner, HTTP-Methoden, gemischte Inhalte, 23 sensible Pfade, Verzeichnislisten, robots.txt, security.txt und 12 Dienst-Ports.
Jeder Fund enthält die rohe Beobachtung und einen Shell-Befehl, um ihn zu reproduzieren.
Prüfungen, die nicht ausgeführt werden konnten, werden als "nicht geprüft" gemeldet - niemals stillschweigend als bestanden.
Berichte lassen sich als Markdown oder JSON herunterladen.
So funktioniert's
1Geben Sie eine Domain ein, für die Sie verantwortlich sind.
2Der Scan führt passive Sonden aus - gewöhnliche Anfragen, keine Ausnutzung.
3Lesen Sie die Funde, jeweils mit Beleg, und überprüfen Sie die, die wichtig sind.
Kein Fund wird erfunden
Der Scanner enthält kein Sprachmodell. Schweregrad, Auswirkung und Behebung sind je Prüfung festgelegt, und jeder Befund entsteht aus einer echten Beobachtung. Der Bericht auf dem Bildschirm und die Downloads als Markdown und JSON entstehen aus denselben Befunden, ganz ohne Modell.
Wie die Note berechnet wird
Die Punktzahl beginnt bei 100 und verliert 34 Punkte je kritischem Befund, 13 je hohem, 5 je mittlerem und 1,5 je niedrigem, mit einer Obergrenze je Schweregrad (hoch 45, mittel 22, niedrig 9). Informative und bestandene Ergebnisse kosten nichts. Ab 90 gibt es ein A, ab 75 ein B, ab 60 ein C, ab 40 ein D, darunter ein F. Eine einzige offen liegende .env-Datei oder ein erreichbarer Datenbank-Port bringt eine sonst saubere Website von 100 auf 66, ein C; zwei solche Befunde ergeben 32, ein F.
Fehlalarme vermeiden
Bevor Pfade wie /.git/HEAD oder /backup.sql geprüft werden, ruft der Scanner eine zufällige Adresse auf, die nicht existieren kann, und merkt sich die Antwort der Website. Ein Pfad gilt nur dann als offen, wenn er HTTP 200 liefert, sich von dieser Nicht-gefunden-Referenz unterscheidet und zur Signatur der jeweiligen Datei passt. Eine Website, die jede URL mit ihrer Startseite beantwortet, zeigt deshalb nicht plötzlich eine Seite voller kritischer Befunde.
Ein fehlerfreier Bericht ist kein Zertifikat
Dies sind passive Prüfungen gegen eine laufende Website. Sie decken nicht die Anwendungslogik, Authentifizierung, Zugriffskontrolle oder irgendetwas hinter einer Anmeldung ab - die Stellen, an denen echte Sicherheitsverletzungen meist beginnen. Prüfungen, die nicht abgeschlossen werden konnten, werden genau aus diesem Grund als nicht geprüft aufgeführt: ein aus einer fehlgeschlagenen Verbindung abgeleitetes Bestehen ist eine falsche Beruhigung, und ein Scan ohne Funde bedeutet, dass nichts gefunden wurde, nicht dass nichts vorhanden ist.
Scannen Sie nur, was Ihnen gehört
Scannen Sie Domains, die Ihnen gehören oder für die Sie eine schriftliche Testerlaubnis haben. Das Tool verweigert Hosts, die zu privaten oder internen Adressen aufgelöst werden, und ist pro IP ratenbegrenzt, aber die Berechtigung bleibt weiterhin Ihre Verantwortung.
Fragen
Ist das ein aktiver Angriff?
Nein. Er sendet gewöhnliche GET-, HEAD- und OPTIONS-Anfragen, führt TLS-Handshakes durch (auch Versuche mit TLS 1.0 und 1.1), DNS-Abfragen über DNS-over-HTTPS von Cloudflare und einfache TCP-Verbindungen zu 12 Ports. Nichts wird ausgenutzt, kein Formular abgeschickt und nichts verändert.
Kann ich jede Website scannen?
Nur solche, die Ihnen gehören oder für die Sie zum Testen autorisiert sind. Das Scannen fremder Infrastruktur ohne Erlaubnis kann an Ihrem Standort rechtswidrig sein.
Warum zeigt eine Prüfung "nicht geprüft" an?
Weil sie nicht abgeschlossen werden konnte - meist, weil auf diesem Ursprung nichts geantwortet hat. Das wird ehrlich gemeldet statt als bestanden verzeichnet.
Kann ich den Bericht exportieren?
Ja, als Markdown oder JSON, eine Stunde lang: Der Bericht liegt so lange im Server-Cache, damit die Downloads funktionieren, und verfällt dann. Kein Export nutzt ein Modell. Der Nutzungseintrag enthält die Zahl der Befunde und die Note, nicht die Domain.
Welche Dateien und Ports werden geprüft?
Dateien: 23 feste Pfade, darunter /.git/HEAD, /.git/config, /.env, /.env.local, /.env.production, /.aws/credentials, /id_rsa, /backup.zip, /backup.sql, /dump.sql, /wp-config.php.bak, /phpinfo.php, /server-status, /actuator/env; jeder wird nur gemeldet, wenn die Antwort zur eigenen Signatur dieser Datei passt. /.well-known/security.txt zählt zu Ihren Gunsten, wenn sie veröffentlicht ist. Ports: ein einfacher TCP-Verbindungsaufbau, nie ein Anmeldeversuch, zu 21 FTP, 23 Telnet, 25 SMTP, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 3389 RDP, 5900 VNC, 11211 Memcached, 8080. Ein erreichbarer Datenbank-Port (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch) oder Telnet gilt als kritisch.
Was melden die SPF- und DMARC-Prüfungen?
Beide Einträge werden aus dem öffentlichen DNS gelesen, auch für eine Website, die keine E-Mails verschickt, denn ohne sie kann jeder E-Mails versenden, die angeblich von Ihrer Domain stammen. Kein SPF-Eintrag ist mittel; ein SPF-Eintrag mit +all, der jeden Server im Internet autorisiert, ist hoch. Kein DMARC-Eintrag unter _dmarc ist mittel; p=none (oder kein p=-Tag) überwacht nur und ist niedrig; p=quarantine oder p=reject besteht. Eine Domain, die gar keine E-Mails verschickt, kann v=spf1 -all veröffentlichen.
Welche Sicherheits-Header werden geprüft, und welcher Wert besteht?
Sechs Header in der Antwort Ihrer Startseite. Fehlen sie, sind HSTS und Content-Security-Policy hoch, X-Content-Type-Options und X-Frame-Options mittel, Referrer-Policy und Permissions-Policy niedrig. Strict-Transport-Security braucht ein max-age von mindestens 15552000 (180 Tage): kürzer ist niedrig, max-age=0 ist mittel. Content-Security-Policy gilt als geschwächt (mittel), wenn script-src 'unsafe-inline' erlaubt, die Richtlinie 'unsafe-eval' erlaubt oder default-src bzw. script-src einen alleinstehenden Platzhalter * enthält. X-Content-Type-Options muss genau nosniff lauten. X-Frame-Options sollte DENY oder SAMEORIGIN sein und ist überflüssig, wenn die CSP frame-ancestors setzt. Referrer-Policy wird nur bei unsafe-url oder no-referrer-when-downgrade gemeldet. Permissions-Policy muss nur vorhanden sein. Zu jedem fehlenden oder schwachen Header gibt es einen curl -sI-Befehl, mit dem Sie selbst nachprüfen können.
Wie prüft es Cookie-Attribute (Secure, HttpOnly, SameSite)?
Es liest jeden Set-Cookie-Header in der Antwort Ihrer Startseite (bis zu 12 Cookies) und prüft bei jedem Secure, HttpOnly und SameSite. Fehlt Secure oder HttpOnly, ist das mittel; fehlt nur SameSite, ist es niedrig, und SameSite=None ohne Secure wird eigens genannt, weil Browser dieses Cookie ablehnen. Ein Cookie mit allen drei Attributen besteht. Die übliche Lösung ist Secure; HttpOnly; SameSite=Lax (in Django: SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY und SESSION_COOKIE_SAMESITE). Der Scan ist nicht angemeldet, Cookies, die erst nach dem Login gesetzt werden, sieht er also nicht. Selbst prüfen mit curl -sI https://your-site/ | grep -i set-cookie
Wie funktioniert die CORS-Prüfung, und wann ist sie kritisch?
Es sendet eine GET-Anfrage an Ihre Startseite mit Origin: https://scanner-probe.example und liest Access-Control-Allow-Origin und Access-Control-Allow-Credentials in der Antwort. Kein Access-Control-Allow-Origin-Header oder ein fester Origin, der den Test-Origin nicht zurückgibt, besteht. Den Test-Origin zusammen mit Access-Control-Allow-Credentials: true zurückzugeben ist kritisch, denn jede Website, die ein angemeldeter Nutzer besucht, könnte seine Antworten lesen. Den Origin ohne Credentials zurückzugeben ist mittel. Ein Platzhalter * ist niedrig, oder mittel, wenn zusätzlich Credentials erlaubt sind (Browser lehnen diese Kombination ab). Geprüft wird nur die Startseite, ohne OPTIONS-Preflight, testen Sie API-Routen also separat mit curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control
Was prüft der TLS-Check (Ablauf des Zertifikats, TLS 1.0 und 1.1)?
Er verbindet sich mit Port 443 und validiert die Zertifikatskette und den Hostnamen. Ein Zertifikat, das nicht validiert, ist hoch, ein abgelaufenes wird zusätzlich als kritisch markiert, und eines mit weniger als 15 Tagen Restlaufzeit ist mittel; andernfalls werden Subject, Aussteller, Ablaufdatum und SAN-Namen als bestanden angezeigt. Das ausgehandelte Protokoll muss TLS 1.2 oder TLS 1.3 sein, alles Ältere ist hoch. Danach versucht er einzeln je einen Handshake mit TLS 1.0 und mit TLS 1.1: Akzeptiert der Server einen davon, gibt es einen mittleren Befund, denn beide sind laut RFC 8996 veraltet. Kann das OpenSSL des Scanners die alte Version selbst nicht anbieten, wird nichts gemeldet statt geraten. Die Lösung in nginx ist ssl_protocols TLSv1.2 TLSv1.3; Prüfen Sie die Daten selbst mit echo | openssl s_client -connect your-site:443 -servername your-site 2>/dev/null | openssl x509 -noout -dates
Prüft es, ob HTTP auf HTTPS weiterleitet?
Ja. Es ruft http://your-site/ auf, ohne Weiterleitungen zu folgen. Ein 301 oder 308 auf eine https://-Adresse besteht. Ein 302, 303 oder 307 auf HTTPS ist niedrig, weil Browser sich eine temporäre Weiterleitung nicht merken und jeder neue Besuch mit einer unverschlüsselten Anfrage beginnt. Eine Seite, die über unverschlüsseltes HTTP ausgeliefert wird (Antwort 2xx), ist hoch. Antwortet Port 80 gar nicht, ist das informativ, kein Fehler. Die Lösung in nginx ist server { listen 80; return 301 https://$host$request_uri; }, danach Strict-Transport-Security ergänzen. Prüfen Sie es selbst mit curl -I http://your-site/
Welche HTTP-Methoden meldet es (TRACE, PUT, DELETE)?
Es sendet eine einzige OPTIONS-Anfrage an Ihre Startseite und liest den Allow-Header, oder Access-Control-Allow-Methods, wenn Allow fehlt. Werden TRACE, TRACK, PUT oder DELETE angeboten, ist das mittel; PATCH oder CONNECT allein sind niedrig; nur Standard-Lesemethoden bestehen. Sendet der Server keinen der beiden Header, wird nichts gemeldet. Dass eine Methode angeboten wird, beweist nicht, dass sie funktioniert, prüfen Sie es also, bevor Sie etwas ändern. TRACE kann die Header der Anfrage samt Cookies an den Aufrufer zurückspiegeln (Cross-Site Tracing). nginx lehnt TRACE standardmäßig ab; bei Apache setzen Sie TraceEnable Off. Beschränken Sie PUT und DELETE auf die API-Routen, die sie brauchen, hinter einer Authentifizierung. Prüfen Sie es selbst mit curl -X OPTIONS -i https://your-site/
Wie erkennt es Verzeichnislisten ("Index of /")?
Es ruft 7 Pfade ab: /, /static/, /assets/, /uploads/, /images/, /files/ und /backup/. Ein Pfad, der mit HTTP 200 und einer Seite antwortet, deren Titel oder Hauptüberschrift mit "Index of /" beginnt, wird als mittel gemeldet (CWE-548), weil die Liste Dateien zeigt, die nirgends verlinkt sind, etwa Backups, Exporte und alte Versionen. Tut das keiner, ist die Prüfung bestanden; ist die Website nicht erreichbar, wird sie als nicht durchgeführt gemeldet. Die Lösung in nginx ist autoindex off; (der Standard, suchen Sie also nach einem ausdrücklichen autoindex on), bei Apache Options -Indexes, danach alles Sensible aus dem Web-Root entfernen. Prüfen Sie es selbst mit curl -s https://your-site/uploads/ | head -20
Findet es gemischte Inhalte und Formulare, die über HTTP senden?
Ja, auf der Startseite. Es liest das HTML so, wie es ausgeliefert wird (JavaScript wird nicht ausgeführt), und listet jedes script-, link-, iframe- oder img-Tag, dessen src oder href mit http:// beginnt. Ist darunter eine .js- oder .css-Datei, ist der Befund mittel, weil ein unterwegs ausgetauschtes Skript oder Stylesheet in Ihrer HTTPS-Seite läuft; nur Bilder und Frames ergeben niedrig; gar keine bedeutet bestanden (CWE-311). Ein Formular, dessen action mit http:// beginnt, gilt als hoch (CWE-319), weil alles, was dort eingegeben wird, auch Passwörter, unverschlüsselt übertragen wird. Abhilfe: diese URLs auf https:// umstellen oder relativ machen und zusätzlich den Header Content-Security-Policy: upgrade-insecure-requests als Sicherheitsnetz setzen. Selbst prüfen mit curl -s https://your-site/ | grep -Eo "(src|href|action)=.http://[^ >]*"
Was prüft es in robots.txt und security.txt?
robots.txt: Es lädt /robots.txt und liest, wenn die Antwort HTTP 200 als Textdatei ist, die Disallow-Zeilen in den ersten 8000 Zeichen. Ein Disallow-Pfad, der admin, internal, private, backup, config, staging, test, api, secret, dev enthält, gilt als niedrig (CWE-200): robots.txt ist öffentlich und bittet nur höfliche Crawler, fernzubleiben, also macht das Auflisten solcher Pfade sie erst bekannt. Schützen Sie sie mit einer Anmeldung und halten Sie Seiten mit noindex aus der Suche. security.txt: Es ruft /.well-known/security.txt ab, den von RFC 9116 festgelegten Ort, und wertet die Datei zu Ihren Gunsten, wenn sie eine Contact:-Zeile hat. Fehlt sie, gibt es keinen Abzug. RFC 9116 verlangt außerdem ein Expires:-Feld, das der Scan nicht prüft, also veröffentlichen Sie beides, zum Beispiel Contact: mailto:security@your-site, Expires: 2027-06-30T23:00:00Z. Selbst prüfen mit curl -s https://your-site/.well-known/security.txt
Was prüft der CAA-Check und wie lege ich einen CAA-Eintrag an?
Er fragt die CAA-Einträge (RFC 8659) des eingegebenen Hostnamens über DNS-over-HTTPS von Cloudflare ab. Findet er welche, ist die Prüfung bestanden und der Nachweis zeigt bis zu 5 davon; findet er keine, meldet er "No CAA record" als niedrig, denn dann darf jede öffentliche Zertifizierungsstelle ein Zertifikat für den Namen ausstellen. Ein CAA-Eintrag nennt die CAs, die Sie tatsächlich nutzen, zum Beispiel your-site. IN CAA 0 issue "letsencrypt.org", dazu 0 iodef "mailto:security@your-site" für Meldungen. Legen Sie pro genutzter CA eine issue-Zeile an und eine issuewild-Zeile, wenn Wildcard-Zertifikate von einer anderen CA kommen sollen. Selbst prüfen mit dig CAA your-site
Warum meldet ein Scan von www oder einer Subdomain kein CAA, SPF oder DMARC?
Jede DNS-Prüfung läuft auf genau dem eingegebenen Namen: www.example.com wird als www.example.com abgefragt, nicht als example.com, und die drei Einträge vererben sich unterschiedlich. CAA: Eine Zertifizierungsstelle, die auf www.example.com keinen CAA-Eintrag findet, geht zu example.com hoch und nutzt diesen (RFC 8659, Abschnitt 3), daher kann "No CAA record" auf einer Subdomain ein Fehlalarm sein. DMARC: Empfänger greifen auf die Richtlinie der Organisationsdomain zurück, die mit sp= eine eigene Richtlinie für Subdomains festlegen kann (RFC 9989, das RFC 7489 ablöst), daher ist ein fehlender Eintrag unter _dmarc.www.example.com meist durch _dmarc.example.com abgedeckt. SPF: Es gibt keine Vererbung (RFC 7208), daher stimmt "No SPF record" für diesen Namen; ein Hostname, der keine E-Mails verschickt, kann v=spf1 -all veröffentlichen. Eine fehlgeschlagene DNS-Abfrage erscheint ebenfalls als fehlender Eintrag. Scannen Sie auch die nackte Domain oder prüfen Sie mit dig CAA example.com und dig TXT _dmarc.example.com