Zum Inhalt springen
← Startseite

Changelog

Alle Updates, neue Features und Verbesserungen an Webalyzr.

Bugfix

Drei Wege, auf denen Empfänger-Daten trotz Bereinigung gespeichert wurden — geschlossen

  • •Bei einer Durchsicht der gespeicherten Daten kamen drei Lücken zutage, durch die Angaben zum Angegriffenen an der Bereinigung vorbeiliefen. Alle drei sind geschlossen, die Altbestände nachträglich bereinigt
  • •Erstens mehrfach kodierte Adressen: Eine Kampagne führte ihre Empfänger-Adresse zweifach Base64-kodiert mit. Die Prüfung dekodierte eine Ebene, fand wieder nur Base64 und ließ den Wert als unverfänglich durch. Jetzt wird bis zu drei Ebenen tief geprüft
  • •Zweitens das Weiterleitungsziel: Es wurde ungeprüft gespeichert. Da Angriffsketten die Empfänger-Kennung von Station zu Station weiterreichen, landete sie darüber im Klartext in der Datenbank — obwohl sie in der eingegebenen Adresse korrekt entfernt worden war. Es durchläuft jetzt dieselbe Bereinigung
  • •Drittens der Seitentitel: Gefälschte Anmeldemasken übernehmen Adresse und Firmendomain des Empfängers in den Titel — eine beobachtete Maske hieß schlicht „kit-group.org". Dieser Titel wurde gespeichert und jedem angezeigt, der denselben Link später prüfte. Adresse, Domain und Firmenname werden dort jetzt ersetzt; die Adresse zu entfernen und die Domain stehenzulassen wäre nur ein halber Schutz gewesen
Verbesserung

Beweisaufnahmen: Adresse wird im Bild unkenntlich gemacht statt das Bild wegzulassen

  • •Bisher wurde bei Adressen mit Empfänger-Kennung versucht, dieselbe Seite ohne Parameter erneut aufzurufen, um ein speicherbares Bild zu bekommen. Das scheiterte regelmäßig: Solche Seiten liefern ohne gültige Kennung nichts oder etwas völlig anderes aus — im beobachteten Fall ein Cookie-Banner von Google. Ergebnis war dann gar kein Bild
  • •Der Umweg ist überflüssig, denn die Seite steht bereits offen. Jetzt werden E-Mail-Adressen direkt im geladenen Dokument überschrieben — in Eingabefeldern, Platzhaltern und im sichtbaren Text — und davon eine zweite Aufnahme gemacht. Gespeichert wird diese; angezeigt wird in der laufenden Prüfung weiterhin das Original
  • •Damit ist die Angriffsseite vollständig dokumentiert und die Adresse des Betroffenen trotzdem nicht gespeichert: Im Bild steht an ihrer Stelle „••••••@••••••". Der Ersatzaufruf ohne Parameter bleibt als Rückfall bestehen
  • •Nebenbei behoben: Die Speicherung bevorzugte das Bild eines Zweitaufrufs, während die Oberfläche das Bild des Hauptdurchlaufs zeigte — gespeichert worden wäre also eine andere Aufnahme als die, die der Nutzer vor sich hat. Beide greifen jetzt auf dieselbe Quelle zu
  • •Ebenfalls behoben: Der Hinweis „Für diese Adresse konnte keine Ansicht aufgenommen werden" erschien, obwohl das Bild die Angriffsseite zeigte. Die Prüfung verglich die Bildquelle nur mit der eingegebenen Adresse und deren Weiterleitungsziel — ausgerechnet das Ende der Kette, wo der Angriff stattfindet, galt damit als unbeteiligte Website. Jetzt zählt jede Station der beobachteten Weiterleitungskette dazu
Verbesserung

Bot-Abfragen werden erkannt, benannt — und wenn möglich regulär passiert

  • •Neu versucht das Prüfsystem, eine Bot-Abfrage zu passieren, statt vor ihr stehenzubleiben: warten, anklicken, erneut nachsehen. Bewusst ohne Lösungsdienste, Bilderkennung oder Token-Handel — die verbreiteten Abfragen sind meist keine Rätsel, sondern Verhaltensprüfungen, die sich auflösen, sobald der Browser echt genug wirkt
  • •Bewusst nicht auf eine Formulierung festgelegt: Statt nach einem festen Text zu suchen, werden alle plausiblen Stellen gesammelt und nach Wahrscheinlichkeit sortiert einzeln angeklickt — erst echte Kontrollkästchen, dann beschriftete Stellen in mehreren Sprachen, dann Schaltflächen, zuletzt die Mitte des Widget-Kastens. Nach jedem Klick wird geprüft, ob die Abfrage weg ist
  • •Ein Detail, das den ersten Anlauf scheitern ließ: Der gesuchte Text steht auch in allen Elternelementen. Wer den ersten Treffer nimmt, erwischt den äußeren Rahmen und klickt links daneben ins Leere. Gemessen auf dem Server: Rahmen bei x=469, Beschriftung bei x=514 — der Klick ging auf 447 statt auf 498. Jetzt gewinnt die kleinste Trefferfläche
  • •Nach dem Passieren wird auf sichtbaren Text gewartet, nicht auf vorhandene Elemente. Die untersuchte Kampagne schickte den Browser noch eine Stufe weiter, und ein Eingabefeld existiert im Dokument längst, bevor die Seite etwas anzeigt — das Bildschirmfoto wäre sonst weiß geblieben
  • •Dafür meldet sich der Prüfbrowser nicht länger als Automat: Der Automatisierungs-Marker ist abgeschaltet, Sprache und Zeitzone sind gesetzt. Das dient nicht dem Aushebeln fremder Schutzmaßnahmen, sondern der Aussagekraft der Messung — wir wollen sehen, was ein gewöhnlicher Besucher sieht, nicht die Sonderbehandlung für Prüfsysteme. Davon profitieren auch Cookie-Scanner und Compliance-Check
  • •Bemerkenswert dabei: Ein Teil dieser Abfragen ist gar keine. Bei einer untersuchten Angriffsseite fand sich weder ein Cloudflare-Rahmen noch das zugehörige Markup — die Box war nachgebaut und schaltete bei einem Klick einfach weiter. Solche Attrappen halten einfache Analysewerkzeuge ab und wirken auf den Empfänger seriös. Deshalb wird notfalls auch auf die beschriftete Stelle geklickt, mit Mausbewegung statt Sprungklick
  • •Gelingt es nicht, bleibt es bei der ehrlichen Auskunft: Das Bild zeigt die Hürde, über den Inhalt dahinter ist nichts bekannt
  • •Das Zeitlimit für den Deep-Scan steigt von 20 auf 55 Sekunden, weil Klickversuche, das Nachladen der Seite dahinter und das Warten auf sichtbaren Inhalt sich summieren. Ausgereizt wird es nur, wenn tatsächlich eine Abfrage im Weg steht
  • •Was dahinter zum Vorschein kam, zeigt, warum sich der Aufwand lohnt: eine gefälschte Anmeldung, die die echte Unternehmenswebsite als Hintergrund lädt und darüber einen Dialog legt — „Sie wurden abgemeldet, bitte erneut anmelden", mit der Adresse des Empfängers bereits eingetragen. Vorher war davon nichts zu sehen, jetzt schlagen zwei zusätzliche Regeln an: die vorbelegte Anmeldemaske und der Umstand, dass das Formular die Eingaben an eine fremde Domain sendet
Verbesserung

Bot-Abfragen vor dem Inhalt werden erkannt und benannt

  • •Gemeldet an einer Aufnahme, die nur „Verify you are human" zeigte. Das Bild stand unter der Überschrift „Ansicht der Zielseite" — dabei war die Seite gar nicht zu sehen, sondern nur die Hürde davor
  • •Solche Abfragen werden jetzt erkannt (Cloudflare Turnstile, reCAPTCHA, hCaptcha und weitere) und ausdrücklich benannt: Das Bild zeigt die Abfrage, nicht den Inhalt. Über die Seite dahinter sagt die Prüfung dann nichts aus — keine Entwarnung, sondern eine offene Frage
  • •Für sich genommen ist eine Bot-Abfrage kein Angriffsmerkmal, viele seriöse Seiten nutzen sie. Steht sie allerdings vor einer Seite auf öffentlichem Objektspeicher, wird das eigens erwähnt: Diese Kombination hält automatische Prüfsysteme fern, während die Abfrage auf den Empfänger sogar seriös wirkt
Bugfix

E-Mail-Adressen hinter dem „#" wurden übersehen — Erkennung und Datenschutz nachgezogen

  • •Aufgefallen an einem Link, der die Adresse des Empfängers nicht als Parameter, sondern im Fragment hinter dem „#" mitführte. Das ist kein Zufall: Ein Fragment wird nie an einen Server übertragen. Es steht in keinem Server-Protokoll, kein Filter auf dem Weg sieht es, und erst das JavaScript der Angriffsseite liest es aus und trägt die Adresse ins Formular ein
  • •Zwei Folgen hatte das Versäumnis. Erstens wurde das Muster „voradressiertes Opfer" nicht erkannt, obwohl es dasselbe ist wie bei einem Parameter. Zweitens — und schwerer — galt eine solche Adresse als nicht personalisiert: Sie landete ungekürzt in der Datenbank, und das Bildschirmfoto wurde gespeichert, obwohl die Seite die Adresse anzeigen kann. Das widersprach unserer eigenen Zusage, entschlüsselbare Adressen vor dem Speichern zu entfernen
  • •Beides ist behoben: Das Fragment wird jetzt genauso ausgewertet und bereinigt wie die Abfrageparameter — für nackte Adressen, parameterartige Fragmente und Mischformen. Bereits gespeicherte Einträge haben wir nachträglich bereinigt
  • •Neu erkannt: missbrauchte Klick-Weiterleiter aus Werbenetzen. Ein Link auf eine Google- oder Facebook-Adresse passiert jeden Reputationsfilter — führt er sein eigentliches Ziel als Parameter mit, ist genau das der Zweck. Wer den Link überfliegt, sieht den bekannten Namen und nicht das echte Ziel
  • •Neu erkannt: Ketten, die auf öffentlichem Objektspeicher enden (Amazon S3, Cloudflare R2, Azure Blob und weitere). Bisher wurde nur die eingegebene Adresse darauf geprüft; lag die Angriffsseite erst hinter zwei Weiterleitungen auf einem Speicherplatz, blieb es unbemerkt
  • •Ebenfalls korrigiert: Die Ersatzaufnahme ohne Parameter wurde als stimmig gewertet, obwohl sie eine fremde Seite zeigte — im beobachteten Fall ein Cookie-Banner von Google. Der Titelvergleich allein genügt nicht, weil Titel und Bild zu verschiedenen Zeitpunkten erfasst werden. Jetzt muss der Aufruf zusätzlich auf seiner Domain geblieben sein, sonst wird kein Bild gespeichert
  • •Der gemeldete Link steigt von 48 auf 100 Punkte, von drei auf sieben Indikatoren
Verbesserung

Phishing-Checker bewertet jetzt, was auf der Seite steht — nicht nur, wohin die Adresse führt

  • •Gemeldet an einer gefälschten cPanel-Webmail-Anmeldung, die nur 42 von 100 Punkten bekam, obwohl das Bildschirmfoto den Angriff unmissverständlich zeigte: eine nachgebaute Anmeldemaske mit bereits eingetragener Adresse des Empfängers, auf einer fremden, offenbar übernommenen Website
  • •Ursache war eine Lücke im Aufbau: Der Deep-Scan fotografierte die Seite zwar, wertete aber nie aus, was darauf zu sehen ist. Die Bewertung stützte sich ausschließlich auf die Adresse und das Verhalten beim Laden — dass dort nach einem Passwort gefragt wird, also das Kernmerkmal von Credential-Phishing, ging überhaupt nicht ein
  • •Neu wird das Anmeldeformular erfasst: ob ein Passwortfeld vorhanden ist, ob bereits eine E-Mail-Adresse eingetragen wurde und wohin das Formular sendet
  • •Daraus drei Bewertungen. Führt die Adresse eine E-Mail mit und fragt die Seite nach dem Passwort dazu, ist das gezieltes Credential-Phishing — legitime Anbieter übergeben Kennungen nicht kodiert per Adresszeile. Ist im Formular eine Adresse vorbelegt, die nicht zur Domain gehört, ist das ebenfalls auffällig: Bei einer echten Anmeldeseite gibt man seine Adresse selbst ein. Und sendet das Formular an eine dritte Domain, fließen die Zugangsdaten nachweislich woandershin
  • •Der gemeldete Fall steigt damit von 42 auf 82 Punkte
Bugfix

Phishing-Checker wertete Aufnahmen der Angriffsseite fälschlich als „Tarnseite" ab

  • •Gemeldet an einer gefälschten Webmail-Anmeldung, die nach dem Laden auf google.com weiterleitet. Das Prüfsystem hatte die Angriffsseite korrekt fotografiert — den bestmöglichen Beleg —, meldete darüber aber „Für diese Adresse konnte keine Ansicht aufgenommen werden" und bezeichnete die geprüfte Seite als unbeteiligte Website
  • •Ursache: Die Prüfung verglich die Herkunft des Bildes nur mit dem Weiterleitungsziel, nicht mit der eingegebenen Adresse. Leitet eine Angriffsseite auf etwas Harmloses weiter, galt eine Aufnahme der Angriffsseite selbst damit als „nicht das erwartete Ziel". In der Meldung standen die beiden Adressen zusätzlich in vertauschter Rolle, sodass dort sinngemäß „google.com leitet auf die geprüfte Seite weiter" zu lesen war
  • •Behoben: Eine Aufnahme gilt als Beleg, wenn sie entweder die eingegebene Adresse oder deren Weiterleitungsziel zeigt. Nur eine dritte, unbeteiligte Domain löst noch den Hinweis aus, und der benennt jetzt korrekt, welcher Aufruf wo gelandet ist
  • •Zwei Folgefehler gleich mit: Das Prüfsystem holte in solchen Fällen zusätzlich ein Bild des Weiterleitungsziels — also von google.com —, obwohl bereits eine Aufnahme der Angriffsseite vorlag. Und die Beleg-Aufnahme für die Beweissicherung orientierte sich ebenfalls am Weiterleitungsziel statt an der fotografierten Seite, sodass bei genau diesen Adressen gar kein Bild gespeichert wurde
Feature

Phishing-Checker sichert Beweise: Was eine Adresse früher zeigte, bleibt nachweisbar

  • •Der Anlass: Zwei Kampagnen dieser Woche lieferten erst ihre Angriffsseite aus und Stunden später eine unbeteiligte Fremdseite. Wer den Link danach prüft, findet nur noch die Fassade — was der Empfänger tatsächlich gesehen hat, war nicht mehr rekonstruierbar. Das Umschalten nach Ende einer Versandwelle ist bei Phishing-Baukästen Standard, weil es Sperrungen und Blocklisten-Einträge verzögert
  • •Jede Prüfung wird deshalb jetzt festgehalten: Titel der Seite, tatsächliches Ziel, HTTP-Status, Bewertung und ein Bildschirmfoto. Eine spätere Prüfung derselben Adresse zeigt diese früheren Aufnahmen mit Datum an — sichtbar wird damit nicht nur, was heute dort steht, sondern auch, was vorher dort stand
  • •Liegt zu einer Adresse noch keine frühere Prüfung vor, wird auf die Kampagne ausgewichen: Ein frischer Link derselben Welle trägt eine andere Empfänger-Kennung, führt aber zur selben Seite. Aufnahmen verwandter Adressen sind dann ebenso aussagekräftig und werden als solche gekennzeichnet
  • •Festgehalten wird nur, was etwas Neues aussagt. Zeigt eine wiederholte Prüfung denselben Zustand, entsteht kein weiterer Eintrag — erst eine Veränderung von Titel oder Zielseite wird vermerkt. Der Vergleich stellt dabei auf den Ziel-Host ab, nicht auf die vollständige Adresse: Angriffsbaukästen vergeben bei jedem Aufruf eine neue Session-Kennung, ein Vergleich der ganzen Adresse hätte bei jeder Prüfung eine Dublette erzeugt
  • •Zum Datenschutz: Gefälschte Anmeldemasken zeigen die Adresse des Opfers regelmäßig im Formular an. Ein Bild davon wäre ein personenbezogenes Datum und würde der Zusage widersprechen, dass solche Adressen vor dem Speichern entfernt werden. Trägt eine Adresse eine entschlüsselbare Empfänger-Kennung, wird deshalb dieselbe Seite ein zweites Mal ohne Abfrageparameter aufgerufen und dieses Bild gespeichert — dieselbe gefälschte Maske, nur ohne vorbelegte Adresse. Der Pfad bleibt dabei erhalten: Die Angriffsseite steckt dort, nicht auf der Startseite
  • •Ob der parameterfreie Aufruf tatsächlich dieselbe Seite zeigt, wird geprüft statt unterstellt — manche Baukästen leiten ohne gültige Kennung auf eine unbeteiligte Seite um. Das Ergebnis dieses Vergleichs steht am Bild. Weicht es ab, ist das kein Mangel, sondern selbst ein Befund: Die Seite macht ihren Inhalt von der Empfänger-Kennung abhängig
  • •Titel und Ziel werden in jedem Fall festgehalten; sie beantworten die Frage „was stand dort früher" auch ohne Bild. Wo trotz allem kein Bild vorliegt, steht der Grund dabei
Bugfix

Tool-Seiten ließen sich auf dem Handy seitlich verschieben — behoben

  • •Auf 47 der 70 Tool-Seiten ragte die Eingabezeile über den rechten Bildschirmrand hinaus, sodass sich die Seite waagerecht schieben ließ. Betroffen war alles mit Eingabefeld und Knopf nebeneinander — von der DNS-Abfrage über den Cookie-Scanner bis zum Portscanner
  • •Ursache war eine Eigenheit von Flexbox: Ein Eingabefeld, das sich den verfügbaren Platz teilen soll, unterschreitet trotzdem nie seine natürliche Eigenbreite. Auf einem 390 Pixel breiten Display blieb für den Knopf daneben schlicht kein Platz mehr, und er wurde nach außen gedrückt
  • •Behoben an der Ursache statt am Symptom: Das Eingabefeld darf jetzt schrumpfen, und auf schmalen Bildschirmen stehen Feld und Knopf untereinander statt nebeneinander — der Knopf nimmt dort die volle Breite ein und ist deutlich besser zu treffen. Ab Tablet-Breite bleibt das Layout unverändert
  • •Zwei Sonderfälle kamen dazu: Beim DKIM- und beim BIMI-Werkzeug hatte das Selektor-Feld eine fest eingestellte Breite, die auf dem Handy nicht passte. Sie gilt jetzt erst ab Tablet-Breite
  • •Nachgemessen mit einem echten Browser über alle 70 Tool-Seiten in iPhone-Breite: vorher 47 Seiten mit Überstand, jetzt keine einzige
Verbesserung

Phishing-Checker erkennt, wenn der Inhalt nicht zur Adresse passt — und sagt ehrlich, warum das offen bleibt

  • •Neu erkannt: der Widerspruch zwischen Adresse und Inhalt. Aufgefallen an einer gefälschten Stripe-Rechnung — die Adresse „stripe-payment-link.com" lieferte eine niederländische Rezept-Website aus. Keine Weiterleitung, dieselbe Adresse, nur ein völlig fremdes Thema
  • •Die naheliegende Erklärung — die Seite erkennt Prüfsysteme an der IP-Adresse und zeigt ihnen eine Fassade — haben wir nachgemessen, und sie hat sich nicht bestätigt: Derselbe Abruf von einem gewöhnlichen Privatanschluss lieferte dasselbe Ergebnis, ebenso mit Session-Cookie, Referer und Empfängerkennung in der Adresse. Wahrscheinlicher ist der Ruhezustand: Phishing-Baukästen schalten nach Ende einer Versandwelle auf harmlosen Inhalt um, weil das Sperrungen und Blocklisten-Einträge verzögert
  • •Die Meldung legt sich deshalb nicht fest, sondern nennt beide Erklärungen — und dass keine davon „harmlos" bedeutet. Was ein Empfänger zum Zeitpunkt des Versands gesehen hat, lässt sich nachträglich nicht mehr feststellen; die Bewertung stützt sich auf die Merkmale der Adresse, nicht auf den heute ausgelieferten Inhalt
  • •Aus demselben Grund neu formuliert: Bisher hieß es bei Weiterleitungen auf unbeteiligte Websites, die Seite schüttele Prüfsysteme gezielt ab, und das belege bösartige Absicht. Diese Behauptung ging weiter als die Belege — auch hier bekam ein normaler Anschluss dieselbe Umleitung. Der Befund bleibt, die Begründung ist jetzt die zutreffende
  • •Erkannt wird der Widerspruch: Eine Adresse, die eine bekannte Marke oder einen Sachbegriff wie Zahlung, Anmeldung oder Sendungsverfolgung ankündigt, deren ausgelieferter Inhalt davon aber kein Wort erwähnt. Der Abgleich läuft mehrsprachig, weil solche Tarninhalte häufig aus fremdsprachigen Vorlagen stammen
  • •Bewusst zurückhaltend gehalten: Der Befund entsteht nur, wenn die Adresse einen konkreten Erwartungswert setzt und der Inhalt lang genug für eine Aussage ist. Bei einem Markennamen im Hostnamen genügt der Widerspruch allein, bei allgemeinen Sachbegriffen müssen weitere Verdachtsmomente hinzukommen — ein Onlineshop mit unpassend gewähltem Seitentitel ist kein Angriff
  • •Das Bildschirmfoto wird entsprechend gekennzeichnet: Passt der Inhalt nicht zur Adresse, steht darüber, dass die Aufnahme nicht zeigt, was ein Empfänger beim Versand gesehen hat. Auch bei allen übrigen hoch eingestuften Adressen steht jetzt ein deutlicher Hinweis am Bild statt nur im Kleingedruckten darunter — gefälschte Anmelde- und Zahlungsseiten sind exakte Nachbauten, ein professioneller Eindruck sagt nichts über die Absicht
  • •Die geprüfte Adresse steht in der Handlungsanweisung jetzt abgesetzt statt im Fließtext. Angriffs-Adressen sind regelmäßig mehrere hundert Zeichen lang, weil sie die Empfängerkennung und teils die gesamte Nutzlast kodiert mitführen — im laufenden Satz sprengte eine solche Zeichenfolge die Box
Verbesserung

Phishing-Checker: vier Lücken geschlossen, die echte Angriffe als harmlos ausgewiesen haben

  • •Ein kritischer Einzelbefund führt jetzt immer zur höchsten Stufe. Bisher entschied allein die Punktsumme — eine gefälschte Stripe-Zahlungsseite wurde als „hohes Risiko" statt „kritisch" eingestuft, weil 64 Punkte unter der Schwelle lagen, obwohl die Regel „imitiert eine bekannte Marke" eindeutig angeschlagen hatte. Wenn eine Prüfung eindeutig ist, schwächt die Gesamtsumme das Ergebnis nicht mehr ab
  • •Kurzlinks, deren Ziel sich nicht ermitteln lässt, gelten nicht mehr als unbedenklich. Manche Weiterleitungsdienste blockieren automatische Prüfungen per Bot-Abwehr — das Ergebnis lautete dann „keine Hinweise auf einen Angriff gefunden", obwohl über das Ziel schlicht nichts bekannt war. Jetzt wird genau das gesagt: Ziel unbekannt, offene Frage, nicht öffnen
  • •Neu erkannt: Weiterleitungen in Messenger-Chats (WhatsApp, Telegram, Signal). Der Link führt direkt in ein Gespräch mit einer Rufnummer — inklusive Angabe des Landes. Solche Links verlagern die Kommunikation dorthin, wo keine Schutzfilter mehr greifen; das ist das übliche Vorgehen bei Anlage-, Job- und Liebesbetrug. Ist zusätzlich die erste Nachricht mit einer bedeutungslosen Kennung vorbelegt, erhöht das die Einstufung — bei echten Kundenservice-Links steht dort ein Klartext-Satz
  • •Neu erkannt: Rufnummern als Parameter in der Adresse. Das ist das Muster des Rückruf-Betrugs — eine erfundene Rechnung nennt eine „Hilfe-Nummer", und wer dort anruft, landet beim Täter, der Fernwartung installieren lassen oder Kartendaten abfragen will. Wird als kritisch gewertet
  • •Neu erkannt: lange Zufallskennungen in der Adresse, mit denen Massenkampagnen den einzelnen Empfänger wiedererkennen
  • •Mehrstufige Weiterleitungsketten werden bis zum Ende verfolgt. Angriffe bestehen oft aus mehreren Zwischenstationen, von denen jede nur auf die nächste verweist — erst die letzte ist die eigentliche Anmeldemaske. Bis zu drei Ebenen werden ausgewertet und jede Station einzeln aufgeführt
  • •Neu erkannt: Zielseiten, die Prüfsysteme gezielt abschütteln. Wird der Prüfbrowser von der verdächtigen Adresse auf eine völlig andere, unbeteiligte Website weitergeleitet, ist das kein Zufall, sondern Tarnverhalten — echte Besucher sehen die Angriffsseite, Prüfsysteme etwas Harmloses. Das wird jetzt als kritischer Befund gemeldet, weil der Umstand allein die Absicht belegt
  • •Neu: Bildschirmfoto der Zielseite. Der Prüfbrowser nimmt am Ende des Scans auf, was ein Besucher tatsächlich zu sehen bekäme — nach allen Weiterleitungen. Bei einer nachgebauten Anmeldemaske ist das die überzeugendste Erklärung, warum ein Link gefährlich ist. Das Bild ist bewusst nicht anklickbar und bei hoher Einstufung als gefährlich gekennzeichnet. Wichtiger Vorbehalt, der auch dabeisteht: Manche Angriffsseiten erkennen Prüfsysteme an der IP und zeigen ihnen harmlose Inhalte — ein unauffälliges Bild ist deshalb kein Freibrief
  • •Neu erkannt: Zwischenseiten, die per JavaScript sofort weiterleiten. Solche Loader zeigen harmlosen Tarninhalt — im beobachteten Fall einen Zeitungsartikel über die Sommerzeit — und schicken den Besucher mit einer Zeile Code zum eigentlichen Ziel. Für Filter sieht das wie eine gewöhnliche Seite aus. Die Zieladresse steht dabei im Klartext im Quelltext und wird jetzt ausgelesen, in die Weiterleitungskette aufgenommen und als eigener Befund gemeldet — ohne dass dafür ein Browser die Seite ausführen muss
  • •Tote Kurzlinks werden als solche benannt: Der Prüfbrowser wertet jetzt Statuscode und Seitentitel der Zielseite aus. Kommt er durch die Bot-Abwehr und findet dort eine Fehlerseite, lautet das Ergebnis „Kurzlink existiert nicht mehr" statt „Ziel nicht ermittelbar" — mit dem Hinweis, dass von diesem Link keine unmittelbare Gefahr mehr ausgeht, die zugehörige Nachricht aber verdächtig bleibt. Nötig ist die Titel-Auswertung, weil manche Dienste ihre Fehlerseite mit Status 200 ausliefern
  • •Zur Einordnung: Länder werden benannt, aber nicht bewertet. Eine Vorwahl ist kein Beweis für Betrug — entscheidend bleibt die Kombination aus unerwarteter Nachricht und unbekanntem Kontakt
Verbesserung

Phishing-Checker sagt jetzt klar, was zu tun ist — und wohin ein Kurzlink führt

  • •Neu und ganz oben im Ergebnis: eine abgestufte Handlungsanweisung in drei Spalten — „Auf keinen Fall", „Jetzt tun" und „Falls bereits geöffnet". Ein Zahlenwert allein beantwortet nicht die Frage, die man beim Prüfen eines Links tatsächlich hat: Darf ich das anklicken, und was mache ich, wenn ich es schon getan habe?
  • •Vier Stufen mit unterschiedlichen Texten: Bei kritischem Befund lautet die Ansage „Auf keinen Fall öffnen" samt Anleitung für den Ernstfall (Gerät vom Netz trennen, nicht herunterfahren, Passwörter von einem sauberen Gerät ändern). Bei mittlerem Risiko steht die Rückfrage beim Absender über einen unabhängigen Weg im Vordergrund — ausdrücklich nicht per Antwort auf die verdächtige Nachricht, weil das Postfach übernommen sein kann
  • •Eindeutige Befunde setzen die Stufe hoch: Liefert eine Adresse eine ausführbare Datei aus oder steht sie in einer Bedrohungsdatenbank, gibt es nichts abzuwägen — dann erscheint immer die schärfste Warnung
  • •Neu: die vollständige Weiterleitungskette. Bei einem Kurzlink ist „wohin führt der Link eigentlich" die erste Frage überhaupt. Bisher stand das Ziel nur als Nebensatz in einer Befundmeldung; jetzt wird jede Station einzeln aufgelistet, das Endziel hervorgehoben
  • •Technischer Hintergrund: Die Kette wird Schritt für Schritt verfolgt statt vom System automatisch aufgelöst — sonst kennt man nur Anfang und Ende, die Zwischenstationen gehen verloren. Zusätzlich wird das Ziel jetzt auch dann ausgegeben, wenn die Adresse direkt einen Download auslöst; in diesem Fall navigiert ein Browser gar nicht und meldete bisher nichts zurück
  • •Die Anweisung wird serverseitig erzeugt und über die API mit ausgeliefert — sie lautet damit in Oberfläche, PDF-Bericht und Schnittstelle identisch und lässt sich unverändert an Kunden oder Kollegen weitergeben
Feature

Port-Überwachung: Alarm, sobald ein Port neu offen ist

  • •Neuer wiederkehrender Check „Offene Ports" im internen Bereich — planbar wie die übrigen Prüfungen (manuell, stündlich, täglich, wöchentlich, monatlich) mit Verlauf und Benachrichtigung
  • •Bewertet wird die Veränderung, nicht der Momentanwert: Dass 80 und 443 offen sind, ist erwünscht und keine Meldung wert. Interessant ist, wenn ein Port dazukommt — ein Container, der an 0.0.0.0 statt localhost bindet, eine entfernte Firewall-Regel, ein Dienst, der beim Update seine Standardkonfiguration zurückbekommt
  • •Der erste Lauf ist bewusst nur eine Bestandsaufnahme ohne Bewertung. Ohne Vergleichswert wäre jede Einstufung geraten
  • •Zwei Stufen: Ein neu geöffneter Port ist eine Warnung — handelt es sich um einen Dienst, der nie öffentlich erreichbar sein sollte (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch, Memcached, RDP, VNC, Telnet, SMB, Docker-API, Kubelet, etcd, Consul), gilt der Check als fehlgeschlagen und die Meldung nennt den Dienstnamen im Klartext
  • •Auch hier gilt die Bindung an verifizierte Domains: Ein dauerhaft geplanter Portscan gegen ein fremdes Ziel wiegt schwerer als eine einmalige Abfrage — er liefe unbegrenzt weiter
  • •Technisch dahinter: Check-Läufe speichern ihren Zustand jetzt strukturiert statt nur als Anzeigetext. Damit können auch künftige Prüfungen Veränderungen über die Zeit bewerten, statt jeden Lauf isoliert zu betrachten
Neues Tool

Drei neue Werkzeuge: Reverse IP, E-Mail-Verifikation und ein Portscanner mit freier Portwahl

  • •Reverse IP (öffentlich): Zeigt, welche Domains sich eine IP-Adresse teilen — plus Reverse-DNS-Eintrag und Netzbetreiber. Der praktische Nutzen ist die Nachbarschaft: Wer sich eine IP mit Spam-Versendern teilt, wird über die IP-Reputation mitbestraft. Das erklärt Zustellprobleme, die man sonst vergeblich in SPF und DKIM sucht. Die Datenquelle ist begrenzt, deshalb wird ein leeres Ergebnis ausdrücklich als „keine Daten verfügbar" ausgewiesen und nicht als „keine weiteren Domains"
  • •E-Mail-Verifikation (öffentlich): Prüft per SMTP-Dialog bis zur Empfängerabfrage, ob eine Adresse zustellbar ist — ohne jemals eine Nachricht zu senden. Mit Catch-all-Erkennung über eine zufällig erzeugte Kontrolladresse: Nimmt die Domain auch erfundene Adressen an, ist jede Aussage über ein einzelnes Postfach wertlos, und genau das steht dann auch da. Ebenso bei Greylisting und bei Anbietern wie Microsoft 365, die Empfängerprüfungen bewusst immer positiv beantworten — ein „gültig" wäre dort geraten
  • •Portscanner mit freier Portwahl (nur interner Bereich): Einzelne Ports und Bereiche wie 22,80,443,8000-8100, bis zu 200 pro Durchlauf. Bewusst nicht öffentlich, denn ein frei konfigurierbarer Portscan gegen fremde Ziele ist ein Aufklärungswerkzeug — erlaubt sind deshalb ausschließlich Domains, die im eigenen Konto verifiziert sind, inklusive ihrer Subdomains
  • •Alle drei mit eigenem Rate-Limit und SSRF-Schutz: Hostnamen werden aufgelöst, private Adressbereiche abgewiesen und die Verbindung geht ausschließlich an die geprüfte IP — ohne erneute Namensauflösung, die dazwischen umgebogen werden könnte
Feature

Interner Bereich: DKIM-Selectors werden überwacht, der Autopilot bekommt einen Vorflug-Check

  • •Neue Karte „DKIM-Selectors": Für jeden Selector, mit dem laut den Reports signiert wird, prüfen wir zweimal täglich, ob im DNS ein gültiger Schlüssel liegt. Zusätzlich werden die gängigen Provider-Selectors (Microsoft selector1/selector2, IONOS s1/s2, Google, weitere ESPs) geprüft, sofern für sie überhaupt ein Eintrag veröffentlicht ist — sonst bliebe der gefährlichste Fall unentdeckt: Ein Anbieter rotiert zwischen zwei Selectors, und der zweite ist tot. Solange der erste benutzt wird, taucht der zweite in keinem Report auf; bei der Rotation schlägt dann schlagartig jede Signatur fehl
  • •Alarm per Mail, sobald ein bisher funktionierender Selector nicht mehr auflöst — mit Debounce, damit ein dauerhaft defekter Eintrag nicht täglich meldet
  • •Vorflug-Check für den DMARC-Autopiloten: Die Ausrichtungsquote allein genügt nicht als Freigabe. Sie kann bei 100 % liegen, während die Domain ausschließlich über SPF besteht — etwa weil ein Versandweg nicht signiert oder ein Selector defekt ist. Bei p=reject würde dann eine einzige Weiterleitung reichen, damit Nachrichten abgewiesen werden. Der Autopilot setzt die Verschärfung in so einem Fall aus, nennt den Grund per Mail und im Verlauf und macht automatisch weiter, sobald es behoben ist
  • •Soll-Profil je Versandweg: Ein freigegebener Versender lässt sich als „muss DKIM signieren" markieren. Fällt er später auf unsigniert zurück — Provider-Umstellung, gelöschter Schlüssel, neues Postfach —, meldet der Alarm das, statt dass es monatelang unbemerkt bleibt
  • •Ausbleibende Reports: Schweigt ein meldender Provider deutlich länger als sonst üblich, erscheint eine Warnung. Typische Ursachen sind ein falscher rua-Eintrag, ein volles Report-Postfach oder ein DNS-Fehler — ohne diesen Hinweis versiegt die Datenlage still
  • •Weiterleitungen werden getrennt ausgewiesen: Nachrichten, deren Sende-IP nicht im SPF steht, die aber eine DKIM-Signatur der eigenen Domain tragen, stammen aus einer Weiterleitung. Solche Fehlschläge sind normal — sie separat zu zeigen erklärt, warum 100 % Ausrichtung selten realistisch sind
Verbesserung

DMARC-Monitoring: sichtbar, womit jeder Versandweg wirklich signiert

  • •Neu in der Versender-Ansicht: eine Aufschlüsselung der DKIM-Signaturen je Versandweg — welcher Selector verwendet wurde, für welche Domain signiert wurde (d=) und wie viele Nachrichten darauf entfielen. Bisher zeigten die Berichte nur, DASS eine Prüfung scheiterte, nicht WOMIT signiert wurde
  • •Vier klar unterschiedene Zustände: gültig & ausgerichtet, ohne Signatur (der Sendeweg signiert gar nicht), gebrochen (Signatur vorhanden, unterwegs zerstört — typisch bei Weiterleitungen) und nicht ausgerichtet (gültig, aber für eine fremde d=-Domain, für DMARC damit wertlos)
  • •Neuer Hinweis für einen Fall, der bisher unsichtbar blieb: Wenn ein Versandweg gar nicht signiert, DMARC aber trotzdem besteht, weil SPF trägt, war das im Dashboard nicht zu sehen — die Diagnose lief nur bei tatsächlichem DMARC-Durchfall. Genau diese Konstellation ist aber ein fehlendes Sicherheitsnetz: Sobald eine solche Mail weitergeleitet wird, bricht SPF und die Zustellung hängt an nichts mehr
  • •Praxisbeispiel aus dem eigenen Betrieb: Eine Domain versendet parallel über Microsoft 365 und IONOS. Über Microsoft wird sauber signiert, über IONOS blieb ein Teil der Nachrichten unsigniert — sichtbar wurde das erst mit dieser Auswertung
Bugfix

Timeouts ziehen den Score nicht mehr nach unten — und drei Tools liefern jetzt dieselbe Antwort

  • •Lief ein Prüfbereich in einen Timeout (typisch beim Performance-Test langsamer Server), ging er bisher mit 0 Punkten in den Gesamtscore ein — obwohl gar keine Messung vorlag. Ein Performance-Timeout kostete dadurch bis zu 10, ein Sicherheits-Timeout bis zu 20 Punkte. Jetzt zählt nur, was tatsächlich gemessen wurde: der Gesamtscore wird auf die gelieferten Bereiche umgerechnet, in der Detailansicht steht beim betroffenen Bereich weiterhin „Timeout"
  • •Scans, die ausschließlich Bereiche ohne Score-Gewicht enthalten (WHOIS, Barrierefreiheit), zeigen keinen Gesamtscore mehr an — statt wie bisher „0" mit der Note „kritisch" für eine Bewertung, die nie stattgefunden hat
  • •Sitemap-Tool: Eine robots.txt darf mehrere Sitemaps nennen. Bisher wurde nur die erste genommen — ist die defekt, endete die Prüfung mit einem Fehler. Bei heise.de etwa ist der erste von sieben Einträgen ein 404, das Tool meldete „HTTP 404" und ignorierte sechs funktionierende Sitemaps. Jetzt werden alle Einträge und danach die Standard-Pfade durchprobiert, bis eine gültige Sitemap antwortet (heise.de: 200 URLs statt Fehlermeldung)
  • •robots.txt-Tool und Technologie-Erkennung nutzen jetzt dieselbe Inhaltsprüfung wie der Hauptscan: eine HTML-Seite mit Status 200 gilt nicht mehr als vorhandene Datei. Damit widersprechen sich Hauptscan und Einzeltools bei derselben Domain nicht mehr
  • •E-Mail-Header-Analyse: Der Satz „Alle drei Authentifizierungsmechanismen haben bestanden" erschien auch dann, wenn der Header nur ein SPF-Ergebnis enthielt — DKIM und DMARC wurden also als bestanden ausgegeben, ohne je geprüft worden zu sein. Jetzt wird benannt, welche Prüfungen vorliegen und welche im Header fehlen
  • •Sicherheit: DMARC-Warnmails maskieren jetzt alle Werte aus eingesendeten Reports (Absender-Domains, IP-Adressen), bevor sie ins HTML der Benachrichtigung gelangen
  • •Aufräumarbeit im Hintergrund: Datenbank-Strukturprüfungen laufen einmal beim Serverstart statt teilweise bei einzelnen Anfragen
Bugfix

Sitemap, robots.txt, ads.txt & Co.: keine Fehlalarme mehr — und die Sitemap wird auch ohne robots.txt-Eintrag gefunden

  • •Die Sitemap wurde bisher ausschließlich über die „Sitemap:"-Zeile in der robots.txt gesucht. Wer seine Sitemap nur in der Search Console einreicht — völlig legitim —, bekam „Keine Sitemap" und 0 von 6 Punkten, obwohl sie existiert. Jetzt werden zusätzlich /sitemap.xml, /sitemap_index.xml, /sitemap-index.xml und /wp-sitemap.xml direkt geprüft und der Inhalt als echtes Sitemap-XML validiert
  • •Neue Abstufung: Sitemap vorhanden und in der robots.txt referenziert = volle Punktzahl. Vorhanden, aber nicht referenziert = 4 von 6 Punkten plus die fertige Zeile zum Kopieren. Nur wirklich fehlende Sitemaps gelten noch als Fehler
  • •Behoben: robots.txt, ads.txt, llms.txt und security.txt wurden allein am Statuscode erkannt. Viele Setups (Single-Page-Apps, manche Hoster) antworten auf jeden beliebigen Pfad mit Status 200 und ihrer normalen HTML-Seite — dadurch galten Dateien als vorhanden, die es nie gab. Jetzt zählt der Inhalt: HTML statt Textdatei wird nicht mehr akzeptiert, Weiterleitungen auf andere Seiten ebenfalls nicht
  • •Bei der security.txt prüfen wir zusätzlich das nach RFC 9116 vorgeschriebene „Contact:"-Feld — eine leere Platzhalter-Datei gilt nicht mehr als erfüllt. Eine ads.txt, die nur aus Kommentaren besteht („keine programmatische Werbung"), bleibt dagegen korrekt als vorhanden gewertet
  • •Wehrt ein Server unsere Anfragen per Anti-Bot-Schutz ab, steht jetzt „nicht prüfbar — bitte manuell aufrufen" statt „fehlt", und die Punkte werden gutgeschrieben. Ein Schutzmechanismus des Hosts soll die Bewertung nicht nach unten ziehen
  • •Dazu ein automatischer zweiter Versuch bei Timeouts und Server-Fehlern (429/5xx): Hosts, die unter Last oder direkt nach einem Deployment wechselhaft antworten, führten sonst zu Zufallsergebnissen
Bugfix

Impressum & Datenschutz in Popups/Modals werden jetzt gefunden — in allen Analysen

  • •Viele Onepager binden Impressum und Datenschutzerklärung nicht als eigene Seite ein, sondern als Popup, das per Button-Klick aufgeht (technisch: <button onclick="openModal(…)"> statt eines normalen Links). Solche Rechtstexte hat der Scan bisher nicht gesehen und „Impressum fehlt" gemeldet, obwohl es vorhanden und für Besucher erreichbar ist
  • •Behoben an allen drei Stellen, die das getroffen hat: der DSGVO-/Compliance-Check, die Rechtlichen Seiten im SEO-Teil des Hauptscans und der Cookie-Scanner (der deshalb „keine Datenschutzerklärung gefunden" schrieb, während der Compliance-Check sie längst fand)
  • •Erkannt werden jetzt Popups/Modals, aufklappende Onepager-Abschnitte und Tab-Layouts — auch dann, wenn die Bezeichnungen keinem Standard folgen. Die Zielsektion wird direkt aus dem Klick-Ziel des Buttons gelesen statt aus Namensmustern geraten
  • •Neu bewertet: Rechtstexte, die es nur als Popup gibt, gelten als vorhanden, bekommen aber einen Hinweis — sie haben keine eigene URL, sind nicht direkt verlinkbar und ohne JavaScript nicht erreichbar. § 5 DDG verlangt „leicht erkennbar, unmittelbar erreichbar und ständig verfügbar", eine eigene Seite (z. B. /impressum) ist daher der sichere Weg
  • •Damit kein falscher Alarm entsteht, prüfen wir zusätzlich den Inhalt: ein aufklappender Cookie-Banner-Kasten, in dem nur das Wort „Datenschutz" vorkommt, wird nicht als Datenschutzerklärung gewertet. Und der Inhalt des jeweiligen Popups wird getrennt geprüft — die Adresse aus dem Datenschutz-Popup zählt nicht als Impressumsangabe
Verbesserung

DSGVO-Check: Consent-Banner ohne Wirkung, Formular-Dienstleister und nicht genannte Drittanbieter

  • •Neu: Wir erkennen Tracking, das schon vor jeder Einwilligung läuft — z. B. ein Meta-/Facebook-Pixel direkt im Seitenkopf, ohne Blockade durch ein Consent-Tool. Google-Tags mit korrekt gesetztem Consent Mode („denied" als Voreinstellung) werden dabei richtig als geschützt erkannt
  • •Neu: Widerspruch zwischen Zusage und Realität. Sagt der Banner „Wir verwenden nur technisch notwendige Cookies" oder „es findet kein Tracking statt", während das Pixel bereits feuert, weisen wir das als eigenen Punkt aus — im Cookie-Scanner zusätzlich mit dem gemessenen Beweis (welches Cookie trotz „Ablehnen" gesetzt wurde)
  • •Neu: Ein Consent-Banner, der technisch nichts blockiert, bekommt im Compliance-Score nicht mehr die volle Punktzahl
  • •Neu: Formular-Dienstleister werden erkannt — schickt das Kontaktformular die Eingaben an einen Drittanbieter (FormSubmit, Formspree, Getform, HubSpot, Mailchimp, Brevo u. a.), ist dieser Auftragsverarbeiter und muss in der Datenschutzerklärung stehen. Wir finden das Ziel auch dann, wenn es nicht im Formular selbst steht, sondern per JavaScript gesendet wird
  • •Neu: Abgleich der eingebundenen Drittanbieter gegen den Text der Datenschutzerklärung — Google Fonts, Google Maps, reCAPTCHA, YouTube, Vimeo, Terminbuchungs- und Chat-Widgets, Bewertungs-Widgets, Zahlungs-Skripte, externe Bildquellen (Unsplash/Pexels) und Skript-CDNs (jsDelivr, cdnjs, Font Awesome, Tailwind-CDN). Was geladen wird, aber nicht genannt ist, wird aufgelistet
  • •Neu: Zeigt die Seite einen Cookie-Banner, während die Datenschutzerklärung Cookies an keiner Stelle erwähnt, ist das jetzt ein eigener Befund
  • •Neu: Platzhalter aus Vorlagen im Impressum („wird noch vergeben", „Musterstraße", Blindtext) werden erkannt — bei optionalen Angaben wie der USt-IdNr. als Hinweis, nicht als Verstoß
  • •Korrigiert: Preise mit vorangestelltem Währungszeichen (z. B. „€2.490") wurden bei der Prüfung auf den Mehrwertsteuer-Hinweis übersehen
  • •Korrigiert: Ein Fehlalarm „Google Analytics ohne US-Transfergrundlage" auf Seiten, die mit Tailwind CSS gebaut sind — bestimmte CSS-Klassennamen wurden für eine Analytics-Kennung gehalten
  • •Korrigiert: „Vom Consent-Tool korrekt blockiert" schreiben wir nur noch, wenn das wirklich gemessen wurde — vorher konnte diese Entlastung auch ohne Messung erscheinen
Verbesserung

Cookie-Scanner: erkennt jetzt auch Verbindungen ohne Cookie + deutlich klarerer Report

  • •Der Cookie-Scanner erfasst jetzt auch datenschutzrelevante Drittanbieter-Verbindungen, die gar kein Cookie setzen — z. B. Google Fonts, gstatic, Google Maps oder eingebettete Schriften. Sie übertragen schon beim bloßen Laden die IP-Adresse an Dritte (bekannt aus dem Google-Fonts-Urteil des LG München I)
  • •Neu: Kennzeichnung „vor der Einwilligung" — der Scanner unterscheidet, ob ein Dienst bereits vor jedem Klick auf den Cookie-Banner kontaktiert wird (Verstoß) oder erst nach der Zustimmung
  • •Klarere Struktur: Eine zustandsbezogene Übersicht zeigt genau, was im getesteten Zustand („Alles ablehnen" bzw. „Akzeptieren") an Cookies, Trackern und externen Verbindungen aktiv ist — jeweils mit kurzer Erklärung, was der Unterschied zwischen Cookie, Tracker und externer Verbindung ist
  • •Aktive vs. blockierte Tracker werden klar getrennt: Man sieht, welche Skripte trotz Ablehnung tatsächlich Cookies setzen und welche das Consent-Banner korrekt blockiert — inkl. Legende zu First-/Third-Party, Secure/HttpOnly-Flags und Cookie-Kategorien
Feature

Neuer Ratgeber: Phishing-Link erkennen & prüfen

  • •Praxis-Anleitung, woran man einen gefährlichen Link erkennt, wie man ihn prüft, ohne ihn anzuklicken, und was bei Verdacht zu tun ist — mit 30-Sekunden-Checkliste, den häufigsten Phishing-Maschen und direktem Draht zum Phishing-Link-Checker
Feature

Interner Bereich

  • •DMARC-Monitoring-Dashboard: wertet DMARC-Aggregat-, Forensic- und TLS-RPT-Reports automatisch aus — mit Ausrichtungs-Quote, Versender-Erkennung, Geo-Karte der Report-Quellen und Zustellbarkeit als Tages-Verlauf (gestapeltes Balkendiagramm + Konformitäts-Donut)
  • •Managed DNS per CNAME-Delegation: DMARC (none → quarantine → reject per Klick), SPF-Flattening (viele Includes → ein einziger Include, unter dem 10-Lookup-Limit) sowie MTA-STS und BIMI — Records werden zentral gehostet und gepflegt, der Kunde setzt einmalig einen CNAME
  • •Full MTA-STS: die Policy-Datei kann zentral von uns gehostet werden — pro Domain eine eigene CDN-Zone mit automatischem Let's-Encrypt-Zertifikat, der Kunde setzt nur einen CNAME. Klare, nummerierte DNS-Checkliste mit Live-Status und Warnung zur Unterscheidung _mta-sts (mit Unterstrich) vs. mta-sts (ohne)
  • •Managed TLS-RPT: Google, Microsoft & Co. berichten täglich, wie viele Zustellungen verschlüsselt gelangen — sichtbar auf der DMARC-Seite
  • •Reputations-/Blacklist-Monitoring der Domains und Sende-IPs gegen die wichtigsten DNSBLs, alle 6 Stunden automatisch — je Domain eine Box mit Coverage-Ring (saubere Listen), Flächen-Verlaufsdiagramm und Blacklist-Status, Alarm bei neuem Eintrag
  • •Wiederkehrende Checks (SSL, DNSSEC, Blacklist, Security-Header u. a.) mit eigenem Zeitplan und Benachrichtigung bei Verschlechterung — nur für verifizierte Domains
  • •Wöchentlicher Report per Mail und sofortige Alarme bei Regressionen (abgeschwächte Policy, verschwundener Record, ablaufendes Zertifikat)
  • •DMARC-Forensic (ruf) datenschutzfreundlich: Opt-in per Checkbox und ausschließlich an eine vom Domaininhaber gewählte Adresse — nie an uns, da Reports Nachrichteninhalte enthalten können. Dazu Live-Vorschau des veröffentlichten DMARC-TXT-Eintrags beim Tippen
  • •Team & Rollen: mehrere Benutzerkonten je Organisation mit abgestuftem Rechtemodell (Owner, Admin, Editor, Viewer), TOTP-Zwei-Faktor-Authentifizierung und verschlüsseltem Audit-Log (nur für Administratoren)
  • •Konto-/Organisationslöschung: beim Löschen räumen wir unsere Seite automatisch ab (Delegations-Einträge und MTA-STS-Hosting bei Bunny.net) und schicken dem Kunden per Mail die Liste der Einträge, die er bei seinem eigenen DNS-Provider entfernen sollte
  • •Rechtstexte: Auftragsverarbeitungsvertrag (AVV, Art. 28 DSGVO) inkl. TOMs und Subprozessor-Liste, Nutzungsbedingungen (B2B) und ein Mitgliederbereich-Abschnitt in der Datenschutzerklärung
  • •Öffentliche Feature-/Registrierungsseite unter /registrieren (Selbst-Registrierung folgt in Kürze; Zugang aktuell auf Einladung)
Feature

Phishing URL Checker mit Google Safe Browsing & RDAP-Domain-Alter

  • •Der Phishing URL Checker prüft URLs jetzt zusätzlich gegen die Google Safe Browsing v4-Datenbank (10.000 Lookups/Tag kostenlos). Damit werden bekannte Phishing-Sites und Malware-URLs erkannt, die noch nicht in URLhaus stehen
  • •Brand-Katalog von 35 auf 80+ Marken erweitert — jetzt mit deutschen Banken (Sparkasse, Volksbank, DKB, ING, Commerzbank, Postbank, Comdirect, N26, Targobank, HypoVereinsbank, …), Schweizer/österreichischen Banken, Lieferdiensten (Hermes, GLS, DPD), Telekommunikationsanbietern (Telekom, Vodafone, O2, 1&1), Behörden (Elster, Finanzamt), Stromanbietern (E.ON, RWE, EnBW, Vattenfall), Crypto-Börsen und Streaming-Diensten
  • •Domain-Alter via RDAP: Frisch registrierte Domains (< 30 Tage) bekommen +18 Score-Punkte. Phisher nutzen typischerweise sehr junge Wegwerf-Domains. Unterstützte TLDs: .com, .de, .net, .org, .io, .app, .eu, .uk, .ch, .at
  • •Hostname-Heuristiken: Buchstaben/Zahlen-Substitution wie "paypa1.com" oder "amaz0n.de" und ungewöhnlich viele Bindestriche werden jetzt als Brand-Lookalike-Muster erkannt
  • •Im Result-Header siehst du jetzt: welche externen Quellen abgefragt wurden, das Domain-Alter in Tagen und die konkreten GSB-Threat-Types (SOCIAL_ENGINEERING, MALWARE, UNWANTED_SOFTWARE, POTENTIALLY_HARMFUL_APPLICATION)
Verbesserung

Tools-Übersicht: Mega-Menu im Header + 4-Spalten-Layout + Live-Suche

  • •Beim Hover über "Tools" im Header öffnet sich jetzt ein Mega-Menu mit allen 62 Tools nach Kategorien gruppiert (Mail & DNS, Sicherheit, SEO, Compliance & DSGVO, Netzwerk, Generatoren). Klick auf "Tools" selbst führt weiter zur Übersichtsseite
  • •Suchleiste oben im Mega-Menu: tippe einen Tool-Namen und die Liste filtert sich live. Strg/Cmd+K springt direkt ins Suchfeld, Esc schließt das Menu
  • •Tooltips bei den Tool-Namen zeigen die Tool-Beschreibung beim Hover
  • •Übersichtsseite /tools auch kompakter: 4-Spalten-Layout auf großen Screens, Sprungnavigation zu den Kategorien, gleiche Live-Suche wie im Mega-Menu
  • •Alle 62 Tools jetzt aus einer zentralen Quelle (lib/tools-catalog.ts) — neue Tools tauchen automatisch in Mega-Menu und Übersicht auf
Neues Tool

7 neue Tools für Mail-Security und Phishing-Schutz

  • •MTA-STS Generator (/tools/mta-sts-generator): erzeugt TXT-Record + Policy-Datei für MTA-STS nach RFC 8461. Mit ID-Auto-Generierung und Sanity-Warnungen
  • •TLS-RPT Generator (/tools/tls-rpt-generator): TXT-Record für SMTP TLS Reporting aus rua-Reporting-Zielen
  • •BIMI Generator (/tools/bimi-generator): BIMI-Record für Markenlogo-Anzeige im Posteingang. Mit DMARC- und VMC-Anforderungs-Prüfung
  • •BIMI SVG Validator (/tools/bimi-svg-validator): prüft SVG Tiny 1.2 PS-Konformität für BIMI. Erkennt verbotene Elemente (Scripts, Animationen, externe Referenzen, Event-Handler), Größen-Limit 32 KB, quadratischer viewBox
  • •Phishing URL Checker (/tools/phishing-url-checker): 15 Pattern-Checks + URLhaus + Google Safe Browsing + RDAP-Domain-Alter. Risk-Score 0-100 mit Klassifikation low/medium/high/critical
  • •DMARC XML Report Analyzer (/tools/dmarc-xml-analyzer): Upload deiner Aggregate-Reports (.xml oder .xml.gz). Aggregiert nach Source-IP mit Pass-/Fail-Rate und inferred Sender (Google Workspace, Microsoft 365, SendGrid, …)
  • •Email Vendor Identifier (/tools/email-vendor-identifier): findet alle Mail-Vendors einer Domain durch SPF/MX/DKIM-Analyse. Erkennt 19 Provider mit Rollen (sending/receiving/authentication) und DNS-Evidence — ideal um Schatten-IT aufzudecken
Neues Tool

SPF Checker, DMARC Checker, DNSSEC Checker, CAA Checker, Security Headers Audit, MTA-STS Checker, TLS-RPT Checker

  • •SPF Checker: parst v=spf1-Record, zählt DNS-Lookups gegen das RFC-7208-Limit von 10 rekursiv über alle Include-Chains, visualisiert den vollen Include-Baum mit allen Mechanismen pro Knoten
  • •DMARC Checker: prüft Policy, pct, rua/ruf-Adressen, externe Report-Authorisierung (_report._dmarc bei Cross-Domain-rua), Subdomain-Policy
  • •DNSSEC Checker: prüft DNSKEY, DS, Chain-Validierung via Google DoH, auditiert Algorithmen-Stärke (warnt vor RSA/SHA-1, empfiehlt ECDSA P-256 / Ed25519)
  • •CAA Checker: prüft CAA-Records mit Inheritance bis zur TLD, parst issue/issuewild/iodef, erkennt Niemand-Mode-Konstellationen die Cert-Renewal blocken
  • •Security Headers Audit: gewichtetes Scoring 0-100 mit Grade A+ bis F für HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Header und Server-Disclosure
  • •MTA-STS Checker (RFC 8461): TXT + HTTPS-Policy parallel prüfen, mode/mx/max_age validieren
  • •TLS-RPT Checker (RFC 8460): rua-Schemas (mailto:/https:) prüfen, Mehrfach-Records melden
Verbesserung

Wissensdatenbank: 5 neue Artikel zu DSGVO & Phishing

  • •Phishing-URLs erkennen: Checkliste mit 15 Indikatoren — Brand-Impersonation, IDN-Homograph, verdächtige TLDs, URL-Shortener
  • •Schatten-IT in der Mail-Infrastruktur: Wer mailt eigentlich für uns? Praktische Anleitung zur Vendor-Inventur
  • •Was Art. 13 DSGVO konkret verlangt: Hoster nennen, Löschfristen, Beschwerderecht Art. 77, US-Transfer mit DPF/SCCs
  • •AGB-Klauseln die in 2026 nicht mehr halten: § 308 Nr. 5 Zustimmungsfiktion, § 309 Nr. 7b/9 Verjährung & Auto-Verlängerung, § 312k Kündigungsbutton
  • •Preisangaben richtig machen: § 1 PAngV Pflichtangaben für B2C, B2B und Kleinunternehmer
  • •Damit jetzt 40 Artikel in 5 Kategorien (E-Mail & DNS, Server-Sicherheit, SEO, DSGVO, Webentwicklung)
Verbesserung

Compliance Check: 11 vertiefte Detail-Prüfungen mit Norm-Verweis

  • •Neuer "Vertiefte Rechtsprüfung"-Block unter dem Compliance Check zeigt strukturierte Findings mit Severity (error/warning/info), Norm-Verweis und konkretem Hinweis
  • •Prüft Hoster-Nennung (Art. 13 Abs. 1 lit. e DSGVO), Payment-Provider-Konsistenz zwischen AGB und Datenschutz, Beschwerderecht Art. 77, Löschfristen pro Datenkategorie, US-Transfer-Mechanismus, § 25 TDDDG als Cookie-Rechtsgrundlage, strukturierte Cookie-Liste, Handelsregister-Eintragung bei Kapitalgesellschaften
  • •AGB-Klausel-Erkennung: 1-Jahres-Verjährung (§ 309 Nr. 7b BGB), Zustimmungsfiktion durch Schweigen (§ 308 Nr. 5), automatische Jahres-Verlängerung (§ 309 Nr. 9), § 312k-Kündigungsbutton-Vorbehalt
  • •Preisangaben: € auf der Homepage ohne MwSt/inkl./zzgl.-Hinweis (§ 1 PAngV)
  • •Onepager-Tab-Erkennung: erkennt JS-Tab-Layouts wie <a href="#" onclick="showLegal(...)"> für Impressum/Datenschutz/AGB
  • •TMG-Verweise → DDG-Migration (Gesetzeswechsel 14.05.2024), EU-OS-Plattform-Abschaltung (20.07.2025), Steuernummer-Leak als Sicherheitsrisiko, "Geschäftsführer" bei Einzelunternehmen, BFSG-Barrierefreiheitserklärung (seit 28.06.2025)
Bugfix

Apex-Domain ohne www.: bei kaputten Setups automatisch auf www.${domain} ausweichen

  • •Symptom: Eine betroffene Domain zeigt im Compliance-Check „Impressum nicht gefunden" und „Datenschutz nicht gefunden", obwohl beide Seiten existieren. Cookie-Scanner liefert `net::ERR_CERT_COMMON_NAME_INVALID` auf dem Apex. SEO-Modul findet kein Title, keine Headings, keine Legal-Pages
  • •Root Cause: Der Apex `domain:443` liefert nur einen 14-Byte-Placeholder (`<h3>test</h3>`) aus dem nginx-Default-vhost mit einem Cert für eine andere Subdomain. Die echte Site läuft ausschließlich unter `www.domain`. webalyzr hat bisher stur `https://${domain}` als Base-URL verwendet — und landete damit auf dem leeren Placeholder
  • •Fix: Neuer shared Helper `resolvePreferredBaseUrl()` in `utils/preferred-host.ts`. Ein leichtgewichtiger HEAD-/GET-Probe vergleicht Apex vs `www.`-Variante: wenn Apex netzwerkmäßig fehlschlägt ODER unter 500 Bytes liefert ODER keine `<a href>`-Tags hat UND die www-Variante substantielleren Content liefert, wird automatisch auf www gewechselt. Ergebnis wird 5 Minuten pro Domain gecached, kostet also höchstens 2 Probes pro Scan
  • •Eingesetzt in: compliance-check, SEO-Modul, cookie-scanner, performance-Modul, security-Modul, accessibility-Modul, sitemap-validator, robots-analyzer, duplicate-meta-finder, sustainability-check, exposed-files, http-protocol-check, external-services. Insgesamt 13 Tools/Module — der Apex-vs-www-Fallback wirkt jetzt überall, wo es auf den richtigen Web-vhost ankommt
  • •Zusätzlich: Chromium-Browser-Pool bekommt jetzt `--ignore-certificate-errors`. Wir scannen GEZIELT Sites mit kaputten/abgelaufenen Certs — vorher brach Chromium hart mit `ERR_CERT_COMMON_NAME_INVALID` ab und lieferte den Cookie-/Accessibility-/Compliance-Tools gar kein DOM. Die Cert-Qualität selbst wird vom ssl-checker separat bewertet, also keine Sicherheits-Regression
  • •Verifikation: Compliance-Score der Testdomain von 0 (alles "Startseite nicht erreichbar") auf 90/100, impressum/datenschutz/cookie-consent alle „pass". SEO-Modul findet 3 Legal-Pages und den echten Seitentitel. Cookie-Scanner erkennt die eingesetzten Matomo-Cookies
Bugfix

DANE/TLSA-Validierung: SPKI-Selector wurde fälschlich über das ganze Zertifikat gehasht — fast jeder DANE-Mailserver wurde als "mismatch" gemeldet

  • •TLSA-Records mit Selector 1 (SubjectPublicKeyInfo) sind die in freier Wildbahn häufigste Form — posteo.de, mailbox.org, mxroute.com und die meisten korrekt konfigurierten DANE-Provider nutzen Selector 1. Das dane-check-Tool hat den Hash für Selector 1 aber über das KOMPLETTE Zertifikat berechnet (mit dem Kommentar „we use the full cert as approximation"), nicht über das SPKI-Feld — Ergebnis: bei jedem korrekt eingerichteten DANE-MX kam „Certificate does not match TLSA record" zurück, plus die Empfehlung „DANE reparieren"
  • •Fix: X509Certificate.publicKey.export({ type: "spki", format: "der" }) liefert die korrekt DER-codierte SPKI, gehasht mit SHA-256/SHA-512 je nach matchingType. Unbekannte Selector- und MatchingType-Werte (z.B. zukünftige RFC-Erweiterungen) geben jetzt explizit „Unsupported" zurück statt eine falsche Validierungsaussage zu liefern
  • •Anlass: Audit am 13.05.2026 — alle DANE-aktivierten Mailserver in unseren Test-Scans waren betroffen
Bugfix

Content-Quality bei SPAs: jede React-/Next.js-Site bekam "Thin Content" als High-Prio-Empfehlung

  • •Bug: Anders als image-optimizer, structured-data, broken-link-checker hatte content-quality keinen SPA-Render-Fallback. Bei React/Next/Vue-Sites enthält das rohe HTML oft nur ein <div id="root"></div> + Skeleton — die Wortzahl lag dann bei 5-20, und die Empfehlung „Sehr geringe Wortzahl, ziele auf 800-1500 Wörter" tauchte trotz einer real 2000+-Wörter-Seite auf
  • •Fix: dasselbe spa-render-Pattern, das die anderen 5 Tools schon nutzen — isLikelySpa()-Heuristik (sparse Links ODER kleines rohes HTML) ODER weniger als 100 Body-Wörter triggert einen Headless-Chromium-Render-Pass, dann wird das gerenderte DOM gemessen. Schneller Static-Pfad bleibt der Default für klassische Server-rendered-Sites
Bugfix

Accessibility-Check: Skip-Link-Custom-Rule produzierte False-Positives bei ~90% aller Sites

  • •Bug: Custom-Check „WCAG 2.4.1 Bypass Blocks" feuerte als Moderate-Violation, sobald der ALLERERSTE <a href> der Seite kein Skip-Link war. Realität: bei den allermeisten Sites ist der erste Link das Logo (Home-Link) oder ein Cookie-Banner-Link. Skip-Links sind WCAG-empfohlen, aber „Bypass Blocks" verlangt nicht „muss erster Link sein" — alternative Techniken (Landmarks via <main>, <nav>, <header>) erfüllen das Kriterium ebenfalls
  • •Fix: Check feuert jetzt NUR noch, wenn weder ein <main>-Landmark NOCH irgendein Skip-Link irgendwo auf der Seite vorhanden ist. Wenn nur das <main> fehlt, aber ein <nav>-Landmark da ist, wird die Severity auf "minor" runtergestuft. Patterns für Skip-Link-Detection erweitert (skipnav, skip-to-content, skip-to-main)
  • •Folge: typische Sites mit ordentlicher HTML5-Landmark-Struktur (<main>, <nav>, <header>, <footer>) bekommen keine künstlichen WCAG-2.4.1-Abzüge mehr — der A11y-Score wird um ~3 Punkte realistischer
Bugfix

Tech-Stack: React-Detection nur via DevTools-Marker — fast keine Produktions-Site wurde als React erkannt

  • •Bug: React-Detection-Heuristik war [data-reactroot] (existiert seit React 18 / Concurrent Mode nicht mehr) ODER html.includes(„__REACT_DEVTOOLS") — der zweite Marker existiert nur, wenn der Endnutzer React DevTools im Browser installiert hat. In Produktion praktisch nie sichtbar. Folge: Tech-Stack-Report meldete bei den meisten React-/Next.js-Sites „kein Framework erkannt"
  • •Fix: Detection greift jetzt auf moderne, in Produktion stabile Marker zurück — data-react-helmet (sehr verbreitet bei SEO-Setups), react-dom/jsx-runtime-Bundle-Pfade, _reactRootContainer, __reactProps$, __reactFiber$, React.createElement-Aufrufe in JS-Bundles. Confidence bleibt bei „medium", weil React selten als alleinige Framework-Aussage ausreicht
  • •Zusätzlich: WooCommerce-Detection toleriert jetzt auch CamelCase-Markup (manche Custom-Themes schreiben „WooCommerce" statt „woocommerce" im HTML)
Bugfix

Blacklist-Check: SORBS DNSBL wurde 2024 abgeschaltet — meldete seither jede IP als "gelistet"

  • •Proofpoint (Eigentümer seit der GFI-Übernahme) hat dnsbl.sorbs.net Ende 2024 stillgelegt. Die Zone liefert seither NXDOMAIN-Wildcards bzw. zeitweise 127.0.0.2 für jede Anfrage. Folge: webalyzr meldete bei jeder zweiten Domain „Auf SORBS gelistet" — auch saubere IPs großer Mail-Provider. Endnutzer haben sich zurecht beschwert
  • •Fix: SORBS aus der DNSBL-Liste entfernt. Plus Kommentar im Code, der dokumentiert WARUM (damit nicht der nächste Audit „mehr DNSBLs hinzufügen" zurück packt). Liste der aktiv geprüften DNSBLs ist damit von 25 auf 24 reduziert
  • •Hinweis: Wildcard-Detection als generelles Safeguard (Sentinel-Query mit bekannt-sauberer IP gegen jede Zone) ist noch nicht implementiert — wenn künftig weitere DNSBLs sterben, müssen sie ebenfalls manuell aus der Liste
Bugfix

Cookie-Scanner: Klaro / Usercentrics / CookieYes wurden erkannt, aber Consent-Cookies nie gesetzt — Tracking-Scripts luden nie

  • •Bug: die CMP-Erkennung (detectedCmp-Variable) listete „klaro", „usercentrics", „cookieyes" korrekt, aber die nachfolgende if/else-Kette zum Setzen der Standard-Consent-Cookies endete bei „complianz" — die drei fielen in den Unknown-CMP-Fallback (Klick auf den Banner-Button), der bei vielen Klaro/UC/CY-Installationen scheitert (Custom-CSS, Shadow-DOM, JS-injizierte Buttons). Folge: Tracking-Scripts luden nie, der Cookie-Report meldete „0 Analytics/Marketing-Cookies" trotz aktivem Google Analytics. Falscher „alles sauber"-Eindruck
  • •Fix: explizite Consent-Cookies pro CMP — `klaro` als URL-encoded JSON mit allen Standard-Services (google-analytics, gtm, matomo, fb-pixel, youtube, vimeo, gmaps), `uc_settings` + `uc_user_interaction` für Usercentrics v3, `cookieyes-consent` als URL-encoded String für CookieYes. accept-all und reject-all werden je separat unterstützt
  • •Plus Deep-Scan-Timing-Refactor: vorher 8 Subpages × bis zu 17s = bis 136s pro Site, was bei MAX_PAGES=4 den ganzen Throughput totgeschlagen hat. Jetzt 3 priorisierte Subpages (shop/checkout/kontakt), waitUntil: "domcontentloaded" statt "networkidle2" (Idle wird auf Sites mit dauer-firenden Tracking-Pixeln nie erreicht), Timeouts 15s → 10s, Settle 2s. Deep-Scan dauert jetzt typischerweise <30s statt bis zu 130s
Bugfix

SPF: Lookup-Counter zählte nicht rekursiv — Sites mit gängigen include:-Chains kamen fälschlich als "valid" durch

  • •Bug: RFC 7208 §4.6.4 verlangt, dass jeder DNS-Lookup beim Auswerten eines SPF-Records gezählt wird, REKURSIV durch alle include:- und redirect=-Targets. webalyzrs Counter zählte aber nur die Mechanismen im ÄUSSEREN Record. Sites mit `include:_spf.google.com include:spf.mandrillapp.com include:servers.mcsv.net` sahen „5/10", real waren es 14+ (jeder include triggert intern weitere Lookups) — Empfangs-Mailserver liefern dann „permerror" und können die Mail komplett ablehnen, ohne dass webalyzr es gemerkt hätte
  • •Fix: rekursiver SPF-Resolver mit Lookup-Counter und Visited-Set. Loop-Detection (`include:foo.com` → `include:bar.com` → `include:foo.com`) explizit als Fehler mit Hinweis „Mailserver liefern permerror und blockieren alle Mails". Hartes Tiefen-Limit bei 10 Verschachtelungsebenen als Schutz vor pathologischen Records
  • •Zusätzlich: DKIM-Validator prüft jetzt die echte Keystärke. Vorher nur „p-Tag-Länge > 100 Zeichen" — das hat 1024-Bit-RSA-Keys (216 Zeichen Base64) als OK durchgelassen, obwohl Gmail/Microsoft 1024-Bit seit 2024 als schwach markieren. Jetzt: Public Key wird Base64-decodiert, als SPKI geparst, RSA-Modulus-Bit-Länge ermittelt. < 1024 = kritisch, < 2048 = warn. t=y (Test-Mode) wird separat erkannt und gemeldet — Empfänger ignorieren Test-Mode-DKIM komplett
Bugfix

SMTP-Open-Relay-Test: False-Positives durch eigene Domain als Sender, False-Negatives durch Greylisting

  • •Bug 1 (False-Positives): MAIL FROM nutzte die getestete Domain als Absender (`test@${domain}`). Viele Mailserver akzeptieren automatisch ihre eigene Domain als MAIL FROM und filtern erst auf Empfänger-Ebene — das hat echte Open-Relays maskiert und gleichzeitig Sites fälschlich als „Open Relay" gemeldet, deren Anti-Spoofing nur foreign-sender-basiert greift
  • •Bug 2 (False-Negatives): 4xx-Responses (Greylisting, Rate-Limit) wurden wie 5xx als „Relay korrekt abgelehnt" interpretiert. Server, die uns beim ersten unbekannten Sender temporär ablehnen (gängige Anti-Spam-Praxis bei Postscreen/Postgrey), bekamen so ein ungerechtfertigtes „pass" — würde der Test 5 Minuten später wiederholt, käme vielleicht ein echtes Problem zum Vorschein
  • •Fix: MAIL FROM nutzt jetzt `probe@webalyzr-scan.invalid` (fremde Domain mit RFC-6761-TLD, garantiert nicht-existent). 4xx wird als „inconclusive" (info) gerendert statt als „pass" — mit dem Hinweis „Greylisting/Rate-Limit, Test bei späterem Scan wiederholen". 5xx auf MAIL FROM gilt als korrekte Ablehnung (Anti-Spoof greift schon dort)
Bugfix

Traceroute: SSRF-Lücke durch TOCTOU + IPv6 wurde gar nicht geprüft

  • •Security-Bug: Der SSRF-Check hat per dns.resolve4 die A-Records aufgelöst, gegen private-IP-Ranges geprüft — und dann tracert mit dem ursprünglichen HOSTNAMEN gestartet. Tracert macht sein eigenes DNS-Lookup (Windows-Resolver, ggf. anderer Cache, andere TTL). Bei kurzer TTL + DNS-Rebinding konnte zwischen Check und Spawn eine private IP zurückkommen — klassischer TOCTOU-Bug, internes Netz von außen scannbar wenn ein Angreifer den DNS-Resolver der getesteten Domain kontrolliert
  • •Bug 2: AAAA-Records wurden gar nicht geprüft. IPv6-Domains, die auf fc00::/7 (Unique-Local) oder ::1 (Loopback) zeigen, kamen ungehindert durch
  • •Fix: A UND AAAA werden parallel aufgelöst, ALLE Adressen gegen isPrivateIp (kennt IPv4-Privat, IPv6-Loopback, IPv6-Link-Local, IPv6-ULA) geprüft. Die zuvor verifizierte IPv4 wird direkt als Argument an tracert übergeben — tracert macht damit kein eigenes Lookup mehr. IPv6-only Hosts werden mit klarer Fehlermeldung abgelehnt (Windows tracert spricht v6 nur mit Extra-Flag, das supporten wir bewusst nicht)
Bugfix

Weitere Detection-Verbesserungen: meta-tag-analyzer, broken-link-checker, image-optimizer, exposed-files, external-services

  • •meta-tag-analyzer auf cheerio umgestellt. Vorher: Regex direkt am HTML-String. Bei React-SSR-Payloads mit __NEXT_DATA__-JSON, das Strings wie `"<title>Old</title>"` im State enthält, zog der erste Regex-Match aus dem JSON-Wert statt aus dem echten <head><title>. Cheerio parst baum-strukturiert und ignoriert Inline-Scripts korrekt
  • •broken-link-checker: isExternal-Check über URL.origin statt startsWith. Vorher: `https://example.com.evil.com/...` wurde mit baseOrigin `https://example.com` als „intern" klassifiziert (startsWith-Match). Jetzt: strikter Origin-Vergleich. Phishing-Domains werden korrekt als extern eingestuft
  • •image-optimizer: totalImages zeigt jetzt die ECHTE Anzahl Bilder auf der Seite, plus ein separates imagesChecked-Feld für die 30er-Stichprobe. Vorher meldete ein Shop mit 80 Produktbildern „totalImages: 30" — der Endnutzer dachte, es gäbe 30 Bilder. Schwelle für „oversized" von 200 KB auf 400 KB hochgesetzt (Hero-Bilder sind heute typischerweise 200-500 KB selbst bei guter WebP-Kompression)
  • •exposed-files (.htaccess): Validator hat akzeptiert, sobald irgendwo „Allow"/„Header"/„Rewrite" im Body stand — manche Theme-Texts (Cookie-Banner „Allow all"), Custom-404-HTMLs ohne <html>-Tag oder JS-Strings haben das fälschlich getriggert. Jetzt: muss mit Apache-Direktive (RewriteEngine/IfModule/Options/AuthType/…) starten ODER mindestens 2 klare Apache-Syntax-Muster enthalten. Genauso für debug.log/error.log — Zeitstempel-Muster (ISO, Apache common log, PHP-Fehler) sind jetzt verpflichtend
  • •external-services Privacy-Mentions: Wortgrenzen-Regex statt substring. Vorher matchte „Hotjar" auch in „wir nutzen kein Hotjar"; jetzt Negations-Kontext-Check (wenn „nicht"/„kein"/„ohne" im 30-Zeichen-Fenster davor steht, zählt es nicht als Erwähnung). Außerdem: zu kurze Mentions (<4 Zeichen wie „GA", „X") werden ignoriert, weil sie zu viele Substring-Treffer produzieren
Verbesserung

SSL-Checker prüft jetzt CAA-Records gegen den tatsächlichen Cert-Issuer

  • •Vorher: CAA-Records wurden vom ssl-checker komplett ignoriert. Eine Site ohne CAA-Record bekam ein perfektes A+, obwohl ein essentielles Security-Control fehlt (CAA verhindert seit 2017, dass nicht autorisierte CAs Zertifikate ausstellen). War ein CAA-Record da, hat ihn niemand gegen den Cert-Issuer der gefundenen Cert-Kette verglichen — Inkonsistenz: dns-lookup zeigte CAA, ssl-checker nicht
  • •Jetzt: drei Status-Kategorien — `ok-none` (kein CAA, beliebige CA erlaubt; Empfehlung: CAA setzen), `ok-allowed` (CAA listet die ausstellende CA korrekt), `mismatch` (CAA listet die ausstellende CA NICHT — kritisches Compliance-Issue). CA-Mapping deckt die häufigsten Public CAs ab: Let's Encrypt, Sectigo/Comodo, DigiCert, GlobalSign, GoDaddy/Starfield, Amazon, Google Trust Services, Cloudflare, ZeroSSL, Buypass, Entrust
Verbesserung

DNS-Tools: konsistente blocked-Status-Klassifizierung, subdomain-finder verlangsamt, port-scanner konsolidiert

  • •dns-propagation: REFUSED/SERVFAIL werden jetzt als „blocked" klassifiziert (Resolver-Policy, keine Propagation-Aussage) statt als generischer „error". ENOTFOUND/ENODATA als „nodata" (Domain kennt, aber kein Record dieses Typs). Propagation-Prozent wird nur über tatsächlich antwortende Resolver berechnet — „blocked" und „error" zählen nicht mehr in den Nenner. Neustar 64.6.64.6 raus (seit 2023 von UltraDNS stillgelegt)
  • •subdomain-finder: BATCH_SIZE von 50 auf 10 reduziert. Viele Auth-NS — besonders kleinere (IONOS-Plesk, Strato, Hetzner) — drosseln ab ~30 QPS pro Source-IP und antworten dann mit REFUSED, was existierende Subdomains als „nicht gefunden" durchrutschen ließ. AXFR läuft jetzt zuerst und alleine; wenn ein Auth-NS einen Zonen-Transfer erlaubt (≥50 Subdomains), wird Brute-Force ganz übersprungen — wir haben die authoritative Liste. Wildcard-Detection einmal pro Run (vorher 2× mit möglicherweise unterschiedlichen IPs durch Round-Robin)
  • •port-scanner: zwei separate Listen — eine im Standalone-Tool (21 Ports), eine im Security-Modul (38 Ports) — durch eine geteilte utils/common-ports.ts ersetzt. Custom-Sophos-Ports (4444, 9443 mit hardcoded Service-Namen „Sophos Admin"/„Sophos User") entfernt — alter Customer-Workaround. Plus Kategorien (expected/admin/critical/legacy) als Basis für faireres Scoring (offener :443 ist erwartet, offener :3306/:6379/:27017 ist kritisch)
Verbesserung

Browser-Tools: networkidle2-Antipattern in performance/seo/cookie-scanner durch domcontentloaded ersetzt

  • •Bug: drei Browser-Tools (performance.service.ts, seo.service.ts, cookie-scanner.service.ts) nutzten `waitUntil: "networkidle2"` mit 15-20s Timeout. Auf Sites mit dauer-firenden Analytics-Pixeln (Hotjar-Recording, Clarity, GA-Realtime) wird Network-Idle NIE erreicht — Folge: kompletter Timeout-Verlust statt graceful degradation, kein LCP/CLS-Wert, kein gerendertes Meta, kein Cookie-Snapshot
  • •Fix: alle drei migriert auf `domcontentloaded` + explizit kontrolliertes Settle-Fenster (2.5-6s je nach Use-Case). Performance bekommt 5s Settle für späte LCP-Updates, SEO 2.5s für JS-injizierte Meta, Cookie-Scanner 6s nach Consent-Reload für GTM → GA → 3rd-party-Cookies. Accessibility-Check war als einziges schon umgestellt — jetzt ist das Pattern überall konsistent
  • •Zusätzlich: accessibility-modul Score-Diskrepanz fixed. Das Tool berechnet 100 - critical*15 - serious*8 - moderate*3 - minor*1 (ungecappt), das Modul packt das in 5 Buckets mit Cap (30/30/20/10/10). Bei 3 critical violations zeigte UI „Accessibility 55" und Breakdown 46 — zwei verschiedene Zahlen. Jetzt: Score = Summe der sichtbaren Findings-Punkte. Single Source of Truth
Bugfix

Sitemap: zwei Guide-URLs mit Umlauten waren 404, plus stale lastModified — jetzt dynamisch aus dem Filesystem

  • •Bug: `/guides/security-headers-erklärt` und `/guides/website-sicherheit-prüfen` standen mit echten Umlauten in sitemap.xml, die Next.js-Routen hießen aber tatsächlich `security-headers-erklärt` und `website-sicherheit-prüfen` (ASCII). Beide Sitemap-URLs lieferten 404 — Google konnte die zwei Guides faktisch nicht indexieren. Verifiziert: die Umlaut-Variante gibt heute noch 404, die ASCII-Variante gibt 200
  • •Root Cause: Sitemap-Datei pflegte die 49 Tool-Slugs und 3 Guide-Slugs als hardcoded String-Array — bei jeder neuen Seite oder Slug-Umbenennung droht Drift zwischen Filesystem und Sitemap
  • •Fix: `app/sitemap.ts` scannt jetzt zur Build-Zeit via `fs.readdirSync` die Verzeichnisse `app/tools/` und `app/guides/` und nimmt alle Unterordner mit einer `page.tsx` auf. Damit fällt der Umlaut-Bug konstruktionsbedingt weg (die Slugs kommen direkt vom Filesystem), und neue Tool-/Guide-Seiten landen automatisch in der Sitemap
  • •Zusätzlich: `lastModified` kommt jetzt aus dem mtime der jeweiligen page.tsx (statt durchgängig 2026-03-18, was selbst nach Code-Änderungen stehen blieb) — gekappt auf das aktuelle Datum, damit kein in-die-Zukunft-Datum entstehen kann. `changeFrequency` und `priority` ergänzt: Homepage `weekly` / 1.0, Core-Pages `monthly` / 0.8, Tools 0.7, Guides 0.6
  • •Output validiert: 63 URLs (11 Core + 49 Tools inkl. Methodik + 3 Guides), alle Slugs entsprechen den tatsächlichen Routen, lastModified spiegelt echte Edit-Zeiten der page.tsx-Dateien
Verbesserung

Backend-Performance: Browser-Pool entbottlenecked und Pro-Modul-Timeouts statt pauschaler 60 Sekunden

  • •Headless-Chromium-Pool war auf max. 2 parallele Pages konfiguriert, der Worker läuft aber mit concurrency=2 × Module-Batch=3 — bis zu 6 Module fragen gleichzeitig eine Page an. Sechs Caller (accessibility, compliance-check, cookie-scanner, performance, seo, spa-render) konkurrierten um zwei Slots, was Scans mit JS-rendering-Tools künstlich serialisiert hat
  • •Default jetzt MAX_PAGES=4, zusätzlich via Env-Variable `BROWSER_POOL_MAX_PAGES` ohne Redeploy hochziehbar — bei mehr RAM auf dem VPS lässt sich der Wert (Page-Context ~150-250 MB) jederzeit anpassen. Idle-Shutdown und Crash-Recovery-Logik bleiben unverändert
  • •Modul-Timeouts: vorher pauschal 60 s für alle 10 Module. DNS und WHOIS sind in 1-2 s fertig — der globale 60-s-Wert war für die zu lang (hängende Scan-Steps bei stillen Resolver-Problemen). Performance und Accessibility brauchen mit Chromium-Render real bis zu 40 s — bei langsamen Sites war 60 s zu knapp
  • •Neue Werte: dns/whois 20 s, blacklist 25 s, mail/http/ssl 30 s, security 45 s, seo 60 s, performance/accessibility 90 s. Fail-fast für die schnellen Module + mehr Luft für die schweren — Gesamt-Scan-Dauer fühlbar gleichmäßiger
Bugfix

PDF-Report-Korrekturen: widersprüchliche Labels, abgeschnittene Erklärungen, ausführlicher Tech-Stack

  • •Widerspruch zwischen UI und PDF behoben: bei DNSSEC und CDN stand im PDF „DNSSEC aktiviert" bzw. „CDN erkannt" mit ROTEM X — was nicht passt. Die `drawCheckRow`-Hilfsfunktion bekommt jetzt optional ein negatives Label, und 32 Aufrufer wurden mit klaren Pass/Fail-Paaren versorgt: „DNSSEC aktiviert" + „DNSSEC nicht aktiviert", „CDN erkannt" + „Kein CDN erkannt", „SPF-Record vorhanden" + „Kein SPF-Record gefunden" usw. Im PDF erscheint jetzt entweder die positive Aussage mit ✓ ODER die negative Aussage mit ✗ — nicht mehr beide kombiniert
  • •Compliance-PDF: BFSG-Hinweis zur Barrierefreiheitserklärung wurde auf 120 Zeichen gekappt und endete nach „… verpflichtet das Barr…". Truncate-Grenze auf 2000 Zeichen erhöht — PDFKit wickelt den Text automatisch um, also kein Layout-Risiko. Vollständiger Hinweis inkl. „wer ist betroffen / wer ausgenommen / Bußgelder bis 100.000 €" steht jetzt drin
  • •Tech-Stack-PDF deutlich ausgebaut: vorher nur dünner Server-Header + flache Liste. Jetzt: getrennte Tabellen pro Kategorie (CMS, Library, JS Framework, …) mit Erkennungs-Sicherheit (sicher/wahrscheinlich/möglich). Korrigiertes Schema-Mapping in der Versions-Prüfung — vorher waren die Property-Namen falsch (`v.name` statt `v.technology`), Tabelle blieb leer. Jetzt mit Diff-Spalte „X Major-Versionen hinterher". Neu: CMS-Probe-Findings als eigene Sektion mit Severity-Badges (KRITISCH/WARNUNG/INFO) — z.B. „wp-login.php öffentlich erreichbar", „/composer.json leakt Version", „User-Enumeration via REST API möglich"
  • •Content-Quality im Haupt-Scan-Report: die ContentQualityDetail-Komponente im Scan-Result-Flow rendert jetzt die Verbesserungs-Vorschläge UND die Einleitung — vorher waren die nur im Standalone-/tools/content-quality-Endpoint sichtbar, nicht im Haupt-Scan. Plus: „Wörter/Sätze/Absätze/Oslash" durch echte Umlaute „Wörter/Sätze/Absätze/Ø" ersetzt
Verbesserung

Sitemap, robots.txt, Mixed-Content, Meta-Tags: konkrete Empfehlungen statt knapper Empty-States

  • •Sitemap-Validator: bei „keine Sitemap gefunden" gibt es jetzt eine Erklärung was XML-Sitemaps bringen (Crawl-Geschwindigkeit, vor allem bei neuen Sites und tieferen Strukturen) und konkrete Anleitungen pro CMS (WordPress mit Yoast/Rank Math, Next.js mit app/sitemap.ts, statische Sites, Online-Generator xml-sitemaps.com). Plus Hinweis Sitemap-in-robots.txt + Submit in Search Console
  • •Robots-Analyzer: bei „keine robots.txt" wird erklärt was robots.txt ist und ob du eine brauchst (technisch optional, praktisch empfohlen wegen Sitemap-Hinweis und AI-Crawler-Kontrolle), eine fertige Vorlage zum Copy-Paste mit Standard-Direktiven und optionalen GPTBot/ClaudeBot/PerplexityBot-Ausschlüssen, plus Tipps zur korrekten Platzierung im Webroot
  • •Mixed-Content: bei „alles sauber" wird jetzt erklärt was Mixed Content überhaupt ist (HTTPS-Site lädt HTTP-Ressourcen → Browser blockiert oder warnt) und warum 0 Treffer ein positives Signal sind. Bei HTTP-Sites gibt es Schritt-für-Schritt-Anweisungen zum HTTPS-Umzug (Let's Encrypt, .htaccess-Redirect, HSTS-Header). Bei gefundenem Mixed Content kommt die Standard-Lösung mit Content-Security-Policy + upgrade-insecure-requests
  • •Meta-Tags-Analyzer: statt nur „missing title" gibt es jetzt priorisierte Empfehlungen pro Tag — wichtige (Title/H1/viewport/Description), empfohlene (Canonical/Open-Graph) und optionale (Twitter-Card/Favicon/lang). Jede Empfehlung mit konkretem Code-Beispiel und Soll-Werten (Title 30–60 Zeichen, Description 120–160 Zeichen, og:image 1200×630px). Plus Einleitung was Meta-Tags überhaupt steuern
Verbesserung

Structured-Data, Content-Quality und Compliance-Check liefern jetzt konkrete Handlungsempfehlungen statt nur „nichts gefunden"

  • •Structured Data: bei leerem Ergebnis erklärt das Tool jetzt, was Schema.org-Markup bringt (Rich Snippets, AI-Search-Citations, Knowledge-Graph) — plus eine Heuristik aus dem HTML, welche Schema-Typen für genau diese Site sinnvoll wären. Erkennt LocalBusiness an Adresse+Telefon, Article an /blog/-Pfaden + Autor-Byline, Product an Preis+Warenkorb-Buttons, FAQPage an Frage-Headlines, BreadcrumbList an sichtbarer Navigation. Jeder Vorschlag kommt mit Priorität, Begründung, Nutzen-Beschreibung und JSON-LD-Vorlage zum Copy-Paste
  • •Content Quality: statt nur „Probleme: Niedrige Wortzahl" gibt es jetzt priorisierte Verbesserungsvorschläge mit konkreten Soll-Werten (z.B. „Aktuell 326 Wörter → Ziel: 800-1500"), Begründung aus den Quality-Rater-Guidelines und Handlungstipps. Bereiche: Inhalt (Wortzahl), Lesbarkeit (Flesch), Struktur (H1/H2, Text-HTML-Ratio), Keywords (Density-Warnung), interne/externe Verlinkung, E-E-A-T-Signale. Plus Einleitung was die Metriken überhaupt bedeuten und woher die Schwellwerte kommen
  • •Compliance-Check / Barrierefreiheitserklärung: jetzt mit explizitem Hinweis, wer ab 28.06.2025 unter das BFSG fällt (B2C-Online-Shops, Banken, Telekommunikation, Personenbeförderung, E-Book-Anbieter) und wer ausgenommen ist (Kleinstunternehmen unter 10 MA + ≤2 Mio € Umsatz; B2B; reine Info-Sites). Damit kleine Sites nicht in Panik geraten und große Anbieter wissen was reinmuss (Konformitäts-Stand, Feedback-Mechanismus, Schlichtungsstelle). Bußgelder bis 100.000 € werden klar genannt
  • •Umlaute überall: 23 Frontend-Dateien hatten noch „prüfen / qualität / verhältnis / Größe / für / über / erklärung" als ASCII-Workarounds. Diese sind jetzt durchgängig auf echte ä/ö/ü/ß umgestellt — sowohl in den Tool-Labels (Cookie-Scanner-Beschreibung, Compliance-Beschreibung etc.) als auch in Page-Titles und Meta-Descriptions
Bugfix

Tech-Stack: keine falschen „WordPress v2"-Anzeigen mehr durch zu lockere Versions-Regex

  • •Symptom: Tech-Stack-Tool zeigte bei manchen WordPress-Sites „WordPress v2 → v6.9.4, Veraltet – 4 Major-Versionen". WordPress 2 gab es zuletzt 2007 — solche Installationen sind in freier Wildbahn praktisch nicht mehr existent. Es war immer ein Detection-Bug
  • •Ursache: Drei kaskadierende lockere Regex-Patterns. (1) Der Generator-Meta-Detect-Regex `WordPress\s+([\d.]+)` matchte auch nur eine einzelne Ziffer wenn der Generator-Content etwas wie „… WordPress 2 Theme" enthielt. (2) Die /readme.html-Probe nutzte `Version\s*([\d.]+)` und matchte beim ersten Treffer — der WordPress-Readme-Changelog enthält aber dutzende „Version 2.0 introduced…"-Phrasen, die ALLE Sites fälschlich als „WordPress 2.0" markiert hätten. (3) Der Version-Check schickte selbst diese single-digit-Versionen durch den Outdated-Vergleich, statt sie als offensichtlich kaputt zu verwerfen
  • •Fix in drei Schichten: alle CMS-Detect-Regexes (WordPress/Joomla/Drupal/TYPO3) erfordern jetzt mindestens X.Y-Format (`\d+\.\d+(?:\.\d+)?`). Die readme.html-Probe schaut nur noch im Header VOR dem ersten `<h2>` (= vor dem Changelog-Abschnitt), wo nur die aktuelle Version steht. Im Version-Check selbst werden detected versions mit weniger als 2 numeric Components stillschweigend übersprungen, statt sie als „4 Major-Versionen veraltet" auszuweisen
  • •Konsequenz: WordPress wird auf Sites, die ihre Version verschleiern, jetzt korrekt als „erkannt, Version unbekannt" geführt — kein Outdated-Score-Abzug mehr durch erfundene Version „2". Echte Outdated-Detections (z.B. jQuery 3.3.1 statt 4.0.0) bleiben unverändert
Verbesserung

Pre-Flight-IP-Block-Check jetzt auch in allen 22 Standalone-/tools-Endpoints

  • •Bisher griff der TCP-Reachability-Check nur am Anfang des Haupt-Scans (/api/scan). Wer ein einzelnes Tool über /tools/&lt;name&gt; aufgerufen hat (Tech-Stack, Mixed-Content, Sustainability, Compliance-Check, …), bekam bei einer geblockten Site einfach ein leeres Ergebnis zurück — irreführend, weil es so aussah als hätten wir die Site analysiert und nichts gefunden
  • •Jetzt: Vor jedem HTTP-basierten Standalone-Tool läuft derselbe TCP-Connect-Probe-Check wie beim Haupt-Scan. Bei Block wird HTTP 422 mit klarer Meldung „Site blockiert unsere Scanner-IP – Lösung: Whitelisting" zurückgegeben. Konkret aktiviert für: redirect-checker, meta-tags, robots-analyzer, sitemap-validator, http-protocol-check, social-media-preview, accessibility-check (+pdf), cookie-scanner, mixed-content, tech-stack, geo-readiness, broken-link-checker, structured-data, page-performance, duplicate-meta, image-optimizer, content-quality, serp-simulator, external-services, exposed-files, compliance-check, sustainability-check
  • •DNS-/SMTP-/WHOIS-/TLS-direct-Tools (dns-lookup, smtp-diagnostics, dkim-validator, blacklist-check, dane-check, tls-cipher-analyzer, port-scanner, subdomain-finder, ssl-checker, bimi-lookup, dns-propagation, ping) bleiben unberührt — die operieren nicht auf Web-Port-Ebene und brauchen den HTTP-Check nicht
  • •Wichtig zur Identifikation gegenüber der Site: der Pre-Flight macht ausschließlich einen passiven TCP-SYN auf Port 443 (und ggf. 80) — kein HTTP-Request, kein User-Agent, kein X-Webalyzr-Header. Die Site sieht nur ein normales SYN-Paket wie von jedem Browser, kann uns also nicht aktiv loggen oder identifizieren. Konkret beobachtet bei buse.de (hinter Sucuri-WAF) und itwerksaar.de (vermutlich fail2ban) — beide blocken Datacenter-IPs flächendeckend
Bugfix

DNS-Modul: Resolver-Failover bei Rate-Limit — keine fälschlich leeren DNS-Reports mehr

  • •Symptom war: ein Scan zeigt nur den A-Record, alle anderen Record-Typen (NS, MX, SOA, TXT, CAA) als „nicht gefunden", obwohl die Domain sauber konfiguriert ist. Score sackt von typischen 80–90 Punkten auf 45 ab, ohne dass sich an der Domain etwas geändert hat
  • •Root Cause: node:dns rotiert die konfigurierte Server-Liste (8.8.8.8 → 1.1.1.1 → 4.2.2.1 → 9.9.9.9) automatisch nur bei TRANSPORT-Fehlern (echter Timeout, Network unreachable). REFUSED- und SERVFAIL-Antworten werden NICHT auf den nächsten Resolver gefailovered — der Fehler wird sofort geworfen und unser safeResolve-Wrapper liefert leeren Default. Wenn der erste Resolver unsere Scanner-IP rate-limited (Google 8.8.8.8 macht das gerne bei häufigen Anfragen aus IONOS-Datacenter-Ranges), schlagen ALLE Record-Lookups in einem Scan still fehl
  • •Fix: jeder DNS-Lookup probiert jetzt explizit alle vier Public-Resolver der Reihe nach in eigenen Resolver-Instanzen. Reihenfolge umgestellt auf Cloudflare → Google → Level3 → Quad9 (Cloudflare gibt seltener REFUSED an Datacenter-IPs). Failover wird ausgelöst bei SERVFAIL, REFUSED, TIMEOUT, CONNREFUSED, BADRESP, CANCELLED und transientem EAI_AGAIN. NXDOMAIN und NODATA bleiben final — das sind echte authoritative Antworten, die alle Resolver gleich geben würden
  • •Konkret beobachtet bei einer realen Testdomain: Score sprang von 45 auf 80, weil unsere Anfragen kurzzeitig bei Google rate-limited waren. Diese Klasse Bug betraf potenziell viele Scans über den Tag verteilt, wann immer 8.8.8.8 unsere IP gedrosselt hat
Feature

Sechs Tools nutzen jetzt Headless-Chromium für authentische Ergebnisse statt nur HTML-Parsing

  • •Mixed-Content: misst jetzt echte Network-Requests via Chromium, nicht nur explizite http://-URLs im HTML. Wesentlich für JS-injizierte Mixed-Content-Fälle (CDN-Loader, dynamische Tracker), die ein Browser tatsächlich blockt — der bisherige Static-Check hat diese Klasse komplett übersehen
  • •External-Services: Browser-Pass auf der Homepage sammelt alle 3rd-Party-Requests via Network-Hook. Google Tag Manager lädt z.B. typischerweise 5–15 weitere Tracker (GA, Pixel, Hotjar, Clarity, …) erst zur Laufzeit nach — vorher haben wir nur den GTM-Bootstrap gesehen. Tracker-Liste verdoppelt sich oft
  • •Sustainability-Check: Page-Weight wird jetzt als Summe aller tatsächlichen Network-Response-Bytes gemessen (Top-Level + CSS + JS + Fonts + Bilder + XHR), nicht mehr nur der HTML-Bytes. Die CO2-Berechnung war bisher systematisch um Faktor 5–20 zu niedrig. Methode wird im Resultat als browser/static ausgewiesen, transparent welche Messung greift
  • •Image-Optimizer: bei SPA-Verdacht oder &lt;3 Bildern im rohen HTML Render-Pass — Next.js-Image-Komponente, lazy-load und galerien injizieren Bilder oft erst clientseitig. Bisher zählte der Check dann „0 Bilder", obwohl die Seite 20+ hatte
  • •Broken-Link-Checker: bei SPA-Heuristik (&lt;10 Links oder &lt;8KB rohes HTML) Render-Pass — React-Router/Next.js-Link-Wrapper erzeugen die a-Tags erst nach Hydration
  • •Structured-Data: wenn rohes HTML 0 ld+json-Blöcke enthält oder SPA-Verdacht besteht, Render-Pass. GTM/Yoast/RankMath/SEO-Press injizieren Schema-Markup oft per JS — vorher unsichtbar für unseren Scanner
  • •Alle sechs Pfade laufen über das schon etablierte browser-pool-Pattern aus dem Compliance-Tool (max. 2 parallele Pages, 60 s Idle-Shutdown, hartes Timeout pro Render, stiller Static-Fallback wenn Chromium nicht verfügbar). Die Static-Pfade bleiben als schneller Default für klassische Server-rendered-Sites bestehen — Browser-Pass schaltet sich nur ein wenn nötig
  • •Routing: die Upgrades wirken sowohl in den /tools/&lt;name&gt;-Standalone-Endpoints als auch in den Bonus-Tools im Haupt-Scan, weil beide Pfade dieselben Service-Funktionen aufrufen
Verbesserung

DNSSEC-Resolver-Anzeige: ehrlichere Konsens-Logik und Klartext-Erklärungen statt nur EDE-Codes

  • •Bisheriges Problem: wenn ein Resolver wie Cloudflare die DNS-Antwort durch eine Policy/ACL geblockt hat (EDE 15–18 „blocked/censored/filtered/prohibited"), wurde das als „unsigned" gezählt — der Resolver hatte aber tatsächlich gar keine DNSSEC-Aussage gemacht, die „noad"-Klassifikation war ein Nebeneffekt der verweigerten Auflösung. Der angezeigte Konsens „DNSSEC unsigned" war dann irreführend, weil er sich faktisch nur auf einen einzigen Resolver stützte
  • •Neuer Per-Resolver-Status „blocked" für EDE 15–18 — eigener Badge in der UI („gesperrt"), eigene Erklärung als Tooltip und im sichtbaren Karten-Text. Diese Antworten zählen NICHT mehr als „unsigned"-Stimme im Konsens
  • •Wenn nach Aussortieren der blocked/error-Antworten weniger als 2 verlässliche Stimmen übrig bleiben, wechselt das Gesamt-Ergebnis auf den neuen Status „inconclusive" — sichtbar als „DNSSEC-Status nicht eindeutig bestimmbar", statt einer falschen Aussage. Score bleibt neutral (5 von 10 Punkten)
  • •Pro Resolver gibt es jetzt eine Klartext-Erklärung auf Deutsch — z.B. „Resolver hat die Antwort verweigert: Resolver durfte nicht antworten (Policy/ACL). Diese Antwort ist keine Aussage über DNSSEC" oder „Resolver hat DNSSEC-Signatur kryptografisch validiert (AD-Flag gesetzt)". Mapping-Tabelle für alle 28 EDE-Codes nach RFC 8914, im Backend lokalisiert
Feature

Contao-Version-Detection verbessert und in den Outdated-Check integriert

  • •Contao-Sites entfernen häufig das Versions-Generator-Meta auf der Homepage als Hardening — vorher konnten wir „Contao erkannt" ausgeben, aber keinen Versions-Abgleich machen. Jetzt versucht der Tech-Stack-Scanner auch /contao/login (Backend-Login-Seite, das Versions-Meta bleibt dort meist) und als Notfall /composer.json (öffentlich erreichbar bei Misskonfigurationen)
  • •Wird eine Version gefunden, läuft sie durch den bestehenden Outdated-Check gegen endoflife.date — markiert die Site als „X Major-Versionen / Y Minor-Versionen / Z Patches hinterher" und „End-of-Life" falls die Cycle abgelaufen ist. Das gleiche Mechanismus, der schon für WordPress, TYPO3, Drupal & Shopware existiert
  • •Reihenfolge in der Tool-Pipeline geändert: CMS-Deep-Probes laufen jetzt VOR dem Versions-Check, damit die per Probe nachgefundenen Versionen (Contao/TYPO3/WP via Backend-Login) im selben Scan ausgewertet werden — vorher musste der Versions-Check einen zweiten Scan abwarten
  • •Regex-Verschärfung: Versions-Patterns matchen jetzt nur noch X.Y- oder X.Y.Z-Formate, damit Linktexte wie „Contao 4 Kurzanleitung" nicht mehr fälschlich als Version „4" interpretiert werden (false-positive aus dem ersten Live-Test gegen eine reale Site)
Verbesserung

Scanner bricht jetzt sauber ab, wenn die Ziel-Site unsere IP blockiert — statt halbem Report

  • •Neuer TCP-Reachability-Pre-Check vor dem eigentlichen Scan: Versucht zweimal eine TCP-Verbindung zu Port 443 (4 s Timeout) und fällt notfalls auf Port 80 zurück. Antwortet keiner der Ports auf das SYN-Paket, wird der Scan gar nicht erst gestartet
  • •Bisher: Wenn ein Hoster die Scanner-IP per Firewall droppt (klassisch nach fail2ban-Block oder WordPress-Security-Plugin), liefen trotzdem 20+ Tools 5–10 Minuten lang in einzelne Timeouts und produzierten einen irreführenden Report mit ~30 Punkten Score und Dutzenden "timeout"-Findings, obwohl die Seite eigentlich gesund ist
  • •Jetzt: Innerhalb von max. 18 Sekunden klare Fehlermeldung im Frontend mit konkretem Hinweis — „Wahrscheinlichste Ursache: Hoster blockiert Scanner-IP (87.106.131.207). Lösung: Beim Hoster um Whitelisting bitten, oder warten bis fail2ban automatisch entsperrt." Score und Report werden nicht erzeugt
  • •Differenziert vier Fehler-Klassen: tcp_timeout (SYN gedroppt — IP-Block), tcp_refused (RST — Webserver down), dns (Hostname nicht auflösbar) und unknown. Jede Klasse bekommt einen passenden Erklärtext, damit man nicht raten muss
  • •TLS-Handshake-Fehler und HTTP-4xx/5xx werden bewusst NICHT vorab abgefangen — die sind wertvoller Scan-Input und werden weiterhin von den einzelnen Modulen (Performance, Security, SEO) als Befund gemeldet
Feature

DNS-Modul: echte DNSSEC-Signaturvalidierung statt nur "ja/nein"-Check

  • •DNSSEC-Test fragt jetzt drei DoH-Resolver parallel ab (Cloudflare, Google, Quad9) und bildet Konsens über das AD-Flag (Authenticated Data) sowie Status-Codes
  • •Vier-Stufen-Klassifizierung statt zwei: valid (alle Resolver bestätigen), unsigned (Domain ohne DNSSEC – legitim), bogus (mind. ein Resolver liefert SERVFAIL + EDE 6-10), partial (gemischte Antworten)
  • •BOGUS-Status wird im Report als kritischer Finding ausgewiesen mit dem konkreten EDE-Code (z.B. "EDE 6: DNSSEC Bogus") – der bisherige AD-only-Check hat eine Bogus-Domain fälschlich als "DNSSEC nicht aktiviert" markiert, was die eigentliche Schwere verschleiert hat (Bogus-Domains sind unter validierender DNS unerreichbar)
  • •UI zeigt zusätzlich pro Resolver eine kleine Karte mit dessen Antwort (AD ✓ / unsigned / SERVFAIL / error) sowie EDE-Code – transparent, welcher Resolver was sagt
  • •Anlass: DENIC ZSK-Rollover-Zwischenfall heute morgen führte zeitweise zu DNSSEC-Bogus für .de-Domains (validierende Resolver gaben SERVFAIL+EDE 6, ohne Validation funktionierte alles). Tool hätte das mit dem neuen Check klar als BOGUS gemeldet statt nur "DNSSEC nicht aktiviert"
Bugfix

SEO-Indexability-Fixes: Soft 404 und Duplicate-Canonical-Probleme beseitigt

  • •/report aus der Sitemap entfernt — die generische /report-URL ohne Domain-Parameter wurde von Google als Soft 404 gewertet, weil sie nur einen kurzen "nicht gefunden"-Hinweis ausgegeben hat. Nur dynamische /report/<domain>-Reports sollen indexiert werden
  • •Empty-States für /report (ohne Domain) und /scan (ohne ID) auf vollwertigen Inhalt erweitert: H1, Erklärtext, was geprüft wird, CTA zur Startseite. Verhindert Soft-404-Klassifizierung durch Google auch wenn jemand direkt auf die generische URL geht
  • •/privacy-Verzeichnis komplett gelöscht: hatte einen Canonical-Tag auf /datenschutz, aber inhaltlich abweichenden Text — Google ignorierte das deklarierte Canonical und meldete "Duplikat – vom Nutzer nicht als kanonisch festgelegt". Plus: Seite war noindex und wurde dafür separat als "durch noindex ausgeschlossen" gemeldet. Footer-/AGB-Verweis zeigt jetzt direkt auf /datenschutz
  • •Hintergrund: Search Console zeigte 6 Coverage-Probleme (3× Soft 404, 1× noindex-Ausschluss, 1× Duplikat ohne Canonical, 1× gecrawlt aber nicht indexiert) — alle dürften nach diesem Deploy auf "behoben" wechseln
Bugfix

Scanner akzeptiert jetzt Domains, die nur über lokales/Provider-DNS auflösen

  • •Pre-Scan-Check "Domain existiert" hat bisher ausschließlich Google Public DNS (8.8.8.8) und Cloudflare (1.1.1.1) angefragt. Manche Domains mit Nameservern wie *.dns-parking.com geben dort SERVFAIL zurück, obwohl die Domain technisch live ist (z.B. seosignals.de) — Scanner hat sie fälschlich als "Domain not found" abgelehnt
  • •Fix in zwei Stufen: (1) Public-Resolver-Liste um Level3 (4.2.2.1) und Quad9 (9.9.9.9) erweitert — node:dns probiert bei Transport-Fehlern automatisch den nächsten Server. (2) Falls alle Public-Resolver SERVFAIL geben, fällt der Pre-Check zusätzlich auf den System-DNS zurück (auf dem VPS systemd-resolved → Provider-DNS) — fängt auch Edge-Cases ab, bei denen wirklich kein Public-Resolver antwortet
  • •Score-Module bleiben unverändert beim Public-DNS-only Pfad — Methodik "wir testen die externe Sicht" bleibt konsistent. Nur der Existenz-Check ist bewusst toleranter, weil eine ablehnende Fehlermeldung gegenüber einer live erreichbaren Domain das größere Übel ist
Bugfix

/scan und /report: Hydration-Mismatch behoben — Scans starten jetzt zuverlässig

  • •Beim direkten Aufruf einer Scan-URL wie /scan?id=337&token=… blieb gelegentlich der Empty-State stehen, statt in den Loading-Spinner und schließlich die Live-Ergebnisse zu wechseln. Ursache war ein useMemo([]) das beim Server-Render mit window===undefined null cachte und beim Client-Hydration zu einem DOM-Mismatch führte
  • •Fix: Params werden jetzt erst nach Hydration via useEffect aus window.location ausgelesen. Initial-State (SSR und erster Client-Render) sind identisch → kein Mismatch → React kann sauber re-rendern, sobald die echten Params verfügbar sind. Gleicher Fix in /report/<domain>
Feature

Compliance-Check: SPA-Erkennung mit Headless-Chromium-Render-Pfad

  • •Bei JS-gerenderten Single-Page-Apps (Next.js/React/Vue-Sites mit dünnem rohem HTML) startet der Compliance-Check jetzt automatisch einen zweiten Pass mit Headless-Chromium und analysiert das voll gerenderte DOM — vorher hat der Cheerio-Static-Parser dort keine Links und Inhalte gefunden und alle Compliance-Items als "warn" markiert
  • •SPA-Heuristik: Homepage hat weniger als 10 sichtbare Links **oder** das rohe HTML ist kleiner als 8 KB → SPA-Verdacht → Browser-Pass. Normale Sites bleiben im schnellen Static-Pfad (~0,5 s)
  • •Auch der Impressum-Inhalts-Check (Adresse, Kontakt, TMG/DDG-Verweis) versucht bei SPA-Verdacht und unklarem Static-Resultat einen Browser-Render-Fallback der /impressum-Seite — damit greift die TMG/DDG-Detection auch bei JS-only-Impressums
  • •Hartes 10-Sekunden-Timeout pro Render-Pass plus stilles Failback auf das Static-Ergebnis, wenn Chromium nicht verfügbar ist oder das Rendering scheitert
  • •UI zeigt einen Hinweis-Banner an, wenn die Startseite per Headless-Chromium ausgewertet wurde — transparent über die Methodik
  • •Impressum-Check warnt zusätzlich, wenn die geprüfte Seite noch auf das TMG (Telemediengesetz) verweist statt auf das DDG (Digitale-Dienste-Gesetz) — TMG wurde am 14.05.2024 durch das DDG abgelöst, Verweise auf das alte Gesetz sind potenzieller Abmahn-Anlass
  • •TMG-Erkennung greift jetzt in beiden Discovery-Pfaden: sowohl wenn der Impressum-Link direkt von der Startseite verlinkt ist als auch wenn er nur über die Standard-URL (/impressum) gefunden wird
  • •UI: "Seite öffnen"-Buttons im Compliance-Tool nutzen jetzt korrektes ö statt der ASCII-Schreibweise
Verbesserung

Compliance-Check: bessere Detection für Impressum/Datenschutz/AGB + ehrliches Mail-Scoring

  • •Impressum/Datenschutz/Barrierefreiheits-Detection deutlich robuster: vorher wurde nur exakter Linktext gegen /^impressum$/ etc. gematcht — Varianten wie "» Impressum", "Impressum / AGB", icon-only Links mit aria-label, oder Footer-Links mit Zusatztext fielen durch das Raster
  • •Neuer findLink-Helper sucht zusätzlich in aria-label, title-Attribut und URL-Pfad — und nutzt Wort-Grenzen statt strict-anchors. Pattern für Datenschutz erweitert um "Datenschutzhinweise", "Datenschutzbestimmungen", "DSGVO", "Privacy Notice/Statement"; für Impressum um "Pflichtangaben", "Anbieterkennzeichnung", "Legal Information"
  • •AGB / Nutzungsbedingungen werden jetzt als 5. Compliance-Item geprüft — informativ, fließt nicht in den Score ein (nur bei Online-Vertragsschluss zwingend). Erkennt "AGB", "Allgemeine Geschäftsbedingungen", "Terms of Service", "User Agreement" etc.
  • •Cookie-Consent-Detection erweitert: Didomi, Iubenda, TrustArc, Sourcepoint, Quantcast Choice, Osano, Termly, Cookie Information, Civic Cookie Control, IAB TCF v2 werden jetzt erkannt — plus self-hosted Patterns (/consent.js mit data-consent-open Triggern, "Cookie-Einstellungen"-Linktext)
  • •Mail-Scoring: nicht-anwendbare Items (DKIM/STARTTLS/MTA-STS/TLS-RPT/BIMI ohne MX-Record) bekommen jetzt 0/0 Punkte und fallen damit aus dem Nenner — vorher gab es volle Punkte als "info", was zu einem irreführenden 82/100 für Domains ohne Mail-Infrastruktur führte. SPF und DMARC bleiben weiterhin durchgängig bewertbar (Anti-Spoofing-Schutz greift auch ohne Mail-Server)
Verbesserung

Sitemap-Discovery folgt jetzt der sitemaps.org-Spec (robots.txt zuerst, /sitemap.xml als Fallback)

  • •Sitemap-Validator-Tool prüft bei Eingabe einer Domain zuerst die robots.txt auf eine Sitemap:-Direktive (kanonische Discovery-Methode laut sitemaps.org, die auch Google und Bing nutzen) — vorher wurde direkt /sitemap.xml angefragt und bei abweichendem Pfad ein 404 als "keine Sitemap" gewertet
  • •Fallback-Pfade wurden um die gängigen Varianten erweitert: /sitemap_index.xml (Yoast), /sitemap-index.xml (Astro-Default), /wp-sitemap.xml (WordPress-Core seit 5.5), /sitemap-0.xml (Astro Multi-File-Output) — Spec erlaubt das ausdrücklich
  • •Result enthält jetzt ein "discovery"-Feld ("robots" / "fallback" / "direct"), das transparent macht, wie die Sitemap gefunden wurde
  • •Gleiche Discovery-Logik wird auch im Duplicate-Meta-Finder und External-Services-Crawler verwendet — vorher haben beide Tools an Sites mit nicht-Standard-Sitemap-Pfaden vorbeigecrawlt und dann nur die Homepage analysiert
  • •Methodology-Text im Tool angepasst: erklärt jetzt explizit die zweistufige Discovery-Reihenfolge
Bugfix

Rechtshinweise auf aktuelle Gesetze umgestellt (DDG/MStV/TDDDG)

  • •Impressum-Seite: § 5 TMG → § 5 DDG, § 7 Abs. 1 TMG → § 7 Abs. 1 DDG, §§ 8 bis 10 TMG → §§ 8 bis 10 DDG (TMG wurde am 14.05.2024 durch das Digitale-Dienste-Gesetz ersetzt)
  • •Impressum-Seite: § 10 Abs. 3 MDStV → § 18 Abs. 2 MStV (MDStV ist bereits 2003 ausgelaufen, RStV wiederum 2020 in den Medienstaatsvertrag aufgegangen)
  • •Compliance-Check-Tool: User-Texte und Tool-Beschreibung auf DDG bzw. TDDDG (statt TTDSG) aktualisiert — sowohl deutsche als auch englische Variante
  • •PDF-Report-Generator und i18n-Tipps: Verweise auf "§ 5 TMG" in Empfehlungstexten und Hilfe-Tooltips ebenfalls auf "§ 5 DDG" umgestellt
  • •Inhaltlich keine Änderung der Pflichtangaben — die Umbenennungen sind redaktionell, aber Verweise auf nicht mehr existierende Gesetze sind potenzieller Abmahn-Anlass
Verbesserung

SMTP-Diagnose: Peer-Reject-Erkennung (4xx/5xx statt Timeout)

  • •Wenn ein Empfänger-MX die Scanner-IP auf Protokollebene ablehnt (typisch 554 Bad DNS PTR bei GMX/web.de/T-Online gegen Cloud-IPs), liest der Handshake-Code den SMTP-Response-Code jetzt explizit aus und meldet ihn als peerRejectCode + peerRejectMessage — statt in den 6s-Timeout zu laufen
  • •Neue Felder tlsStarttls.peerRejectCode und tlsStarttls.peerRejectMessage im Result
  • •Recommendation-Engine: Peer-Rejects werden als INFO-Finding "MX lehnt Scanner-IP ab" ausgewiesen — ausdrücklich mit dem Hinweis, dass das keine Fehl-Konfiguration der gescannten Domain ist, sondern eine IP-Reputations-Policy des Empfängers
  • •Frontend-TLS-Panel zeigt bei Peer-Reject eine eigene Amber-Box mit Code + Text statt der generischen "Handshake fehlgeschlagen"-Meldung
  • •Banner und STARTTLS-Probe sowie Submission-Port-587-Probe nutzen jetzt alle einen gemeinsamen readSmtpResponse-Helper, der SMTP-Response-Codes strukturiert parst
Verbesserung

SMTP-Diagnose: Scanner-Reputations-Awareness (dreistufige Outbound-Erkennung)

  • •Neues Feld outboundConnectivity mit den drei Stufen full / partial / none ersetzt das binäre portsBlocked-Flag
  • •Scanner probed sich selbst gegen 6 Referenz-MXe (Gmail, Outlook, Hotmail, GMX, T-Online, freenet) statt wie bisher nur drei
  • •Frontend zeigt farbcodierte Banner: rot (komplett blockiert, z.B. IONOS vor Freischaltung), amber (eingeschränkte Mail-Reputation, z.B. Cloud-IP mit generischem PTR), kein Banner (alles grün)
  • •Recommendation-Engine unterdrückt TLS-Handshake-Timeouts als Findings, wenn der Scanner sich in partial-Connectivity befindet — dadurch keine falschen "STARTTLS fehlgeschlagen"-Meldungen bei Domains mit Google-/GMX-MXen
  • •Methodology-Text an neue Realität angepasst: nicht mehr "Hoster blockt Port 25", sondern "manche MXe filtern Scanner-IP-Ranges nach Reputation/PTR"
Feature

Blacklist-Check: Seriositäts-Einstufung + UCEPROTECT-Aufklärung

  • •DNSBL-Liste von 20 auf 25+ Einträge erweitert (Truncate, Hostkarma, Invaluement, Manitu NiX Spam, Spamhaus Sublisten einzeln)
  • •Jede Liste bekommt jetzt Metadaten: Betreiber, Seriositäts-Tier (Industrie-Standard / Verbreitet / Nische / Umstritten), Delisting-URL, Fokus-Beschreibung, Pay-to-Delist-Flag
  • •Return-Codes werden übersetzt: z.B. "127.0.0.2 → SBL (bekannter Spam-Versender)" bei Spamhaus ZEN
  • •Prominente Warnbox wenn auf kontroverser Liste gelistet (UCEPROTECT L1/L2/L3) mit Link zum Knowledgebase-Artikel
  • •Zusammenfassung trennt nach Industrie-Standard-Hits vs. Umstrittene-Liste-Hits – nicht alle Listings sind gleich relevant
  • •Expandable Table-Rows zeigen Focus/Warning/Delisting-Link pro Liste inline
  • •Knowledgebase-Artikel "IP-Blacklisting: Ursachen & Lösungen" erweitert: klare Trennung seriöse vs. umstrittene Listen, Sektion zur Sippenhaft-Mechanik von UCEPROTECT L2/L3, RFC 6471-Zitat zum Pay-to-Delist-Modell, explizite Empfehlung nicht die Express-Gebühr zu zahlen
Feature

SMTP-Diagnose: TLS-Handshake, DANE, AUTH-Audit, Mail-DNS-Stack + Recommendations

  • •STARTTLS-Handshake auf Port 25 mit echtem TLS-Upgrade: Protokoll, Cipher, Forward-Secrecy, Zertifikat (Subject/Issuer/SAN/Wildcard/Ablauf/SPKI-Hash), SAN-vs-MX-Hostname-Matching
  • •Implicit-TLS-Probe auf Port 465 (SMTPS) mit Cert-Parse
  • •Submission-Port 587: EHLO + STARTTLS-Handshake + AUTH-Mechanism-Audit (PLAIN/LOGIN-vor-TLS-Warnung)
  • •DANE/TLSA-Lookup + Verifikation gegen SHA-256-Hash des Live-Certs (usage=3, matching=1)
  • •VRFY/EXPN-User-Enumeration-Test
  • •All-MX-Enumeration: IPv4 + IPv6 + PTR + Port-25-Reachability pro Prio-Stufe
  • •Kompletter Mail-DNS-Stack: SPF (mit Qualifier/Include-Parse), DMARC (p/sp/rua/ruf/adkim/aspf), DKIM-Probe über 13 gängige Selektoren, MTA-STS (DNS + .well-known-Policy-Fetch + Mismatch-Check), TLS-RPT, CAA, BIMI, Nameserver
  • •MX-Blacklist-Check gegen Spamhaus ZEN, Spamcop, SORBS, Barracuda, CBL
  • •Regelbasierte Recommendation-Engine (kritisch/hoch/info) mit fertigen DNS-Snippets
  • •Scanner-Self-Test: erkennt blockierten Port 25 outbound (Hoster-Default) und zeigt entsprechendes Info-Banner im Frontend, damit TLS-Live-Daten nicht als "broken" missverstanden werden
Feature

Exchange-Check: volle Intelligence-Suite + Recommendation Engine

  • •TLS-Intelligenz pro Host (domain, mail., autodiscover.): Zertifikat (Subject, Issuer, SAN, Wildcard-Erkennung, Ablauf-Tage) + TLS-Version-Matrix 1.0/1.1/1.2/1.3
  • •SMTP EHLO-Collector: kompletter Handshake mit Feature-Parse, STARTTLS-Verhandlung, Protokoll/Cipher-Erkennung, Exchange-native vs. Exim/Postfix-Gateway-Fingerprint
  • •Port-Exposure: TCP-Probes auf 25, 443, 465, 587, 993, 995 gegen mail.-Host
  • •Mail-DNS-Stack: SPF mit Qualifier- und Include-Parse, DMARC mit p/sp/rua/ruf/adkim/aspf-Breakdown, DKIM-Selector-Probe (13 gängige Namen), MTA-STS (DNS + .well-known-Policy-Fetch), TLS-RPT, CAA, BIMI, Nameserver
  • •MX-Blacklist-Check: Spamhaus ZEN, Spamcop, SORBS, Barracuda, CBL
  • •Recommendation Engine: priorisierte Handlungsempfehlungen (kritisch/hoch/info) mit fertigen DNS-Snippets zum Kopieren
  • •False-Positive-Fix: Issues werden nur noch bei echten Exchange-Endpunkten gefeuert (vorher hat Apache-Catch-all auf Main-Domain "OWA publicly accessible" etc. ausgelöst)
  • •Erweiterte Endpoint-Probes: EWS, MAPI, RPC, ActiveSync, OAB, PowerShell, API jetzt auch auf mail.-Subdomain, Best-Pick bevorzugt Exchange-confirmed
Feature

Drupal + Shopware Deep-Probes + Report-Pages SEO-optimiert

  • •Shopware-Detection präzisiert: Meta-Generator + /themes/Frontend/ + /bundles/storefront/ statt nur Name-Match
  • •Drupal Deep-Probe: CHANGELOG.txt-Check (verrät Version), /user/login, /sites/default/settings.php (CRITICAL wenn offen), Module-Extraktion aus sites/all/modules
  • •Shopware Deep-Probe: /recovery/install/index.php CRITICAL-Alarm, Admin-Backend-Check, API-Version-Leak /api/_info/version, /files/documents/ Directory-Listing, SW5-Plugins + SW6-Bundles
  • •Report-Pages (/report/domain.com): dynamische Canonical, Open-Graph + Twitter-Cards, erweitertes TechArticle-Schema mit about-Entity, BreadcrumbList-Schema
  • •robots.txt referenziert jetzt zwei Sitemaps: Next.js-Static (Core-Pages) + Backend-Dynamic (alle Report-URLs) — damit Google alle gescannten Domains als Long-Tail-Content indexieren kann
Verbesserung

Accessibility + HSTS-Preload-Ready

  • •Score-Badge-Farben überarbeitet: Kontrast gegen /15-Hintergründe von 1.4 auf WCAG-AA-kompatibel angehoben (lime-400 → lime-700, yellow-500 → yellow-700)
  • •Nested-Interactive-Elements behoben: Recent-Scans-Cards auf der Homepage nutzen jetzt stretched Link + relative Delete-Button statt role="button" mit verschachteltem Button
  • •H1-Duplikat auf Homepage entfernt: SEO-Content-Block ist jetzt H2 (nur Hero-Heading bleibt H1)
  • •Language-Toggle-Button: min. 32x32px Klickfläche (WCAG 2.5.8)
  • •HSTS: doppelte Security-Header entfernt (Apache + Nginx) — nur noch Nginx setzt Header
  • •HTTP-Scoring: Server-Header und X-Powered-By als warn mit Teilpunkten statt fail (Security-through-Obscurity ist umstritten)
  • •HTTP-Scoring: Custom-404 als warn statt fail (UX-Empfehlung, nicht Pflicht)
  • •Webalyzr.de selbst ist nach den Fixes laut hstspreload.org-API preload-eligible (errors: [], warnings: [])
Bugfix

Scoring fairer: Mail/DNS/SEO bestrafen nicht mehr fehlende Optional-Features

  • •Mail-Modul: Domains ohne MX-Records werden nicht mehr mit 85 Punkten bestraft (DKIM, STARTTLS, MTA-STS, TLS-RPT, BIMI sind ohne Mail-Versand nicht anwendbar)
  • •Mail-Modul: SPF und DMARC bleiben auch ohne MX relevant — als Anti-Spoofing-Schutz mit reduziertem Gewicht (warn statt fail)
  • •Mail-Modul: BIMI-Record nicht mehr als Fehler — BIMI hat <1% Adoption und benötigt ein Verified Mark Certificate
  • •DNS-Modul: CAA-Records und IPv6 (AAAA) als "warn" statt "fail" — optional, nicht verpflichtend
  • •DNS-Modul: MX ohne Records ist jetzt neutrale Info (Domain kann bewusst nur Web-Domain sein)
  • •SEO-Modul: Hreflang-Tags bei Single-Language-Sites (nur <html lang="xx">) als "info" 2/2 statt "fail" 0/2
  • •Security-Header-Check: Accept-Encoding: identity erzwingen, um Plesk/Nginx-Brotli-Quirks zu umgehen
  • •Empirische Score-Änderungen: vercel.app Mail von ~0 auf 82/100, webalyzr.de SEO auf 100/100, Security auf 87/100
Neues Tool

Neues Tool: AI-Search-Readiness (GEO-Check)

  • •Prüft die Sichtbarkeit in ChatGPT, Perplexity, Google AI Overviews und Bing Copilot
  • •AI-Crawler-Check für GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended u.a. in robots.txt
  • •llms.txt-Validierung (Title/Description/Sections/Links)
  • •Schema-Analyse mit Fokus auf FAQPage, HowTo, Organization, BreadcrumbList
  • •Passage-Citability: fragebasierte Headings + Block-Länge (optimal 134-167 Wörter laut Ahrefs-Studie)
  • •SSR-Check (AI-Crawler führen kein JavaScript aus)
  • •Freshness-Check und Entity-Linking via sameAs
  • •Gewichteter Gesamtscore 0-100 mit konkreten Handlungsempfehlungen pro Finding
Verbesserung

Homepage: FAQPage- und HowTo-Schema für AI-Extraktion ergänzt

  • •FAQPage-Schema mit den 4 Homepage-FAQs (Kosten, Score-Berechnung, Datenschutz, Unterschied zu SSL Labs/MXToolbox)
  • •HowTo-Schema für die 3-Schritt-Anleitung zur Website-Analyse
  • •AI-Assistenten wie ChatGPT und Perplexity können Antworten direkt aus diesen Blöcken zitieren
  • •Eigener GEO-Score durch die Änderungen von 84 auf 90 gestiegen
Feature

Tech-Stack: CMS-Deep-Probes für WordPress, TYPO3 und Contao

  • •WordPress: exakte Version aus /readme.html und /wp-json/, Checks für User-Enumeration (REST API + ?author-Redirect), xmlrpc.php und wp-login.php
  • •TYPO3: Backend-Login-Check /typo3/, CRITICAL-Alarm wenn LocalConfiguration.php öffentlich, typo3temp-Directory-Listing, Extension-Erkennung aus typo3conf/ext-Pfaden
  • •Contao: exakte Version aus Generator-Meta, Backend-Login-Check, CRITICAL-Alarm wenn contao-manager.phar.php erreichbar, /files/-Directory-Listing, Modul-Erkennung aus Asset-Pfaden
  • •Contao-Detection präzisiert: statt fragilem html.includes("contao") jetzt harte Signale (Generator-Meta, /assets/contao/, data-contao)
  • •Alle Probes laufen parallel und fail-safe mit 6s-Timeout pro Request
Bugfix

Scoring-Korrekturen: Port-Scanner, DANE, Broken-Link-Checker

  • •Port-Scanner: Bug behoben, bei dem offene riskante Ports keine Punktabzüge gaben (Score stand fälschlicherweise immer auf 100)
  • •DANE-Check: Neue bedingte Bewertung. Ohne MX-Records wird DANE jetzt als "nicht anwendbar" markiert statt mit 50/100 abgestraft
  • •DANE-Check: Fehlerhafte DANE-Records (20), DANE ohne DNSSEC (60), korrekt konfiguriert (100)
  • •Broken-Link-Checker: 429 (Rate-Limit) und 403 (Blocked) werden nicht mehr als "broken" gewertet, sondern als eigene Statuskategorien ausgewiesen
  • •Broken-Link-Checker: Sanftere Prüfung - sequenziell pro Host mit 400ms Delay, honoriert Retry-After, nutzt Browser-User-Agent
  • •Broken-Link-Checker: Fallback von HEAD auf GET bei 403/405/415/429/501
Verbesserung

Broken-Link-Checker: URLs jetzt klickbar

  • •Alle gefundenen Links sind jetzt direkt anklickbar und öffnen sich in einem neuen Tab
  • •Ermöglicht schnelle manuelle Überprüfung von als "broken" gemeldeten URLs
  • •Gilt sowohl für das Bonus-Tool als auch für die Ergebnisse im Hauptscan
Verbesserung

Hosting- und DNS-Provider-Erkennung via Nameserver

  • •Nameserver-basierte Provider-Erkennung mit 80+ Patterns (IONOS, Strato, Hetzner, All-Inkl, GoDaddy, Cloudflare u.v.m.)
  • •DNS NS-Lookup als Fallback wenn WHOIS-Text keine Nameserver liefert (betrifft .de, .energy und viele weitere TLDs)
  • •Neues Feld "DNS-Provider" im Hosting-Check und Whois-Modul
  • •Hetzner-Nameserver (your-server.de, second-ns.de) korrekt erkannt
Verbesserung

Cookie-Klassifizierung: Hardcoded-Daten in Datenbank migriert

  • •Alle 700+ Cookie-Definitionen (Provider, Kategorien, Beschreibungen) von hardcoded Arrays in die Datenbank verschoben
  • •Crawler überschreibt manuelle Korrekturen nicht mehr (source: manual vs cookie.is)
  • •Neue DB-Felder: Subcategory, Privacy-URL, Match-Patterns (Regex), Source-Priorität
  • •Admin-Endpoint zum Seeden und Aktualisieren der Klassifizierungsdaten
  • •Wix-Cookies (svSession, ssr-caching) korrekt als "necessary" klassifiziert
Feature

Cookie-Datenbank mit 1.300+ Einträgen

  • •Umfangreiche Cookie-Datenbank mit Klassifizierung nach Kategorie, Provider und Zweck
  • •259 manuell kuratierte Einträge mit Provider-Zuordnung, Regex-Patterns und Datenschutz-URLs
  • •Saubere Kategorie-Verteilung: Necessary, Analytics, Marketing, Preferences
Neues Tool

Cookie-Scanner (DSGVO Cookie-Analyse)

  • •Browser-basierter Scan mit Puppeteer + Fetch-Fallback
  • •Erkennung von 50+ Consent-Management-Plattformen
  • •Klassifizierung von Cookies in 4 Kategorien mit Provider-Zuordnung
  • •Deep-Scan-Modus: analysiert mehrere Unterseiten
  • •DSGVO-Score mit konkreten Handlungsempfehlungen
  • •Erkennung von 40+ Tracking-Skripten (Google Analytics, Meta Pixel, HubSpot etc.)
Feature

Webalyzr Launch - Kostenlose Website-Analyse

  • •Hauptscan mit 10 Modulen: DNS, Mail (SPF/DKIM/DMARC), HTTP-Headers, SSL/TLS, Blacklist, SEO, Performance, Security, WHOIS und Accessibility
  • •130+ automatisierte Checks mit Scoring-System (0-100 Punkte)
  • •PDF-Report-Export mit detaillierten Ergebnissen und Handlungsempfehlungen
  • •Scan-Verlauf mit Vergleichsfunktion zum Tracken von Verbesserungen
  • •30+ Bonus-Tools: SPF/DMARC/DKIM-Generator, SSL-Checker, DNS-Lookup, Redirect-Checker, Port-Scanner, Whois-Lookup, Meta-Tag-Generator, Robots-Generator, CSP-Generator, htaccess-Generator u.v.m.
  • •Erweiterte Tools: Subdomain-Finder, TLS-Cipher-Analyse, Broken-Link-Checker, Sitemap-Validator, Structured-Data-Validator, Compliance-Check, Tech-Stack-Erkennung
  • •Knowledgebase mit Fachartikeln zu DNS, SSL, E-Mail-Sicherheit und Webstandards
  • •Zweisprachig (Deutsch/Englisch) mit automatischer Spracherkennung
  • •Datenschutzfreundlich: keine Benutzerkonten, keine Cookies, rein passive Analyse
  • •Backend: Fastify + TypeScript mit Redis/BullMQ Queue-System
  • •Frontend: Next.js 14 mit statischem Export und Tailwind CSS