Websites herunterladen, die MDBootstrap nutzen

Über MDBootstrap

Frontend-Bibliotheken sind der Teil eines Tech-Stacks, den ein Scan zuverlässig auslesen kann, denn die Dateien stehen im Markup, und die Release-Nummer ist in den Pfad geschrieben. MDBootstrap ist einer der Fälle, in denen die Erkennung präzise ist und die Interpretation trotzdem Sorgfalt verlangt.

MDBootstrap ist ein JavaScript-Interface-Kit des Anbieters MDBootstrap, das Material-Design-Gestaltung über das Bootstrap-Raster legt, 2015 erschien und im Lizenzmodell Freemium vertrieben wird, mit einer kostenlosen Stufe und kostenpflichtigen Editionen. Der Einsatz auf einer Website sagt eher etwas über die Entwickler aus als über das Unternehmen: Jemand wollte einen vollständigen, sofort einsatzbereiten Komponentensatz innerhalb eines Rastersystems, das er bereits kannte, und nahm dafür ein schweres Paket aus Stylesheets und Skripten in Kauf, um Buttons und Modals nicht von Grund auf gestalten zu müssen.

Stand Oktober 2026 erkennen wir MDBootstrap auf 9.503 Websites. 5.779 davon verorten wir in den USA, und bei den Domains ist die Endung .com am stärksten vertreten. Die Verteilung einer Komponentenbibliothek folgt dem Entwicklermarkt und nicht dem Verbrauchermarkt, weshalb das Bild anders aussieht als bei einer Hosting-Marke oder einem Website-Baukasten. Die Verbreitung läuft über Tutorials, Vorlagen für Admin-Dashboards und Starter-Kits von Agenturen, und so handelt es sich bei den entstehenden Websites eher um interne Tools, Dashboards, Portale und Marketingseiten von Unternehmen als um private Websites.

Bei den Versionsdaten wird die Datei interessant. Derzeit sehen wir 54 verschiedene Releases von MDBootstrap im Einsatz, mit einem Schwerpunkt bei Version 4.19.1. Frontend-Bibliotheken aktualisieren sich nicht selbst. Ein Release wird an dem Tag, an dem eine Website live geht, fest in einen Build eingebunden und bleibt dann fixiert, sodass die Streuung der Versionen über einen Bestand ziemlich direkt zeigt, wann jede dieser Websites zuletzt neu gebaut wurde und wie weit ihre Abhängigkeiten seitdem abgedriftet sind.

Zwei Zielgruppen nutzen diese Streuung. Sicherheitsforscher interessiert sie, weil eine fixierte clientseitige Abhängigkeit ein konkreter Befund zur Software-Lieferkette ist und weil das Wissen, welche Websites welches Release einsetzen, aus einem allgemeinen Sicherheitshinweis einen gezielten macht. Kommerzielle Teams interessiert sie, weil eine veraltete Interface-Bibliothek ein verlässliches Merkmal einer Website ist, an der bald Arbeit ansteht, und weil die installierte Basis eines Produkts mit kostenloser und kostenpflichtiger Stufe Kunden und Nichtkunden desselben Anbieters enthält, und zwar so vermischt, dass der Anbieter sie anhand seiner eigenen Abrechnungsdaten nicht trennen kann.

Die Erkennung hat Grenzen, die man benennen sollte, bevor jemand eine Kampagne darauf aufbaut. Wir identifizieren die Bibliothek anhand von Asset-Pfaden, Mustern in Klassennamen und Skriptsignaturen. Eine Website, die die Bibliothek in ein einziges Bundle kompiliert, die Ausgabe umbenennt oder ungenutzte Teile per Tree-Shaking entfernt, kann deshalb überhaupt keinen erkennbaren Fingerabdruck zeigen, und das Release, das wir melden, ist unter Umständen das aus dem Dateinamen und nicht das des Codes in der Datei. Der Fehler geht wahrscheinlich in Richtung Untererfassung, und moderne Build-Werkzeuge verschieben ihn jedes Jahr weiter in diese Richtung.

Sind diese Vorbehalte benannt, beantwortet der Export eine Frage, die keine Einzelabfrage pro Domain klären kann. Nicht, ob eine Website die Bibliothek nutzt, was Ihnen jeder Browser im Handumdrehen zeigt, sondern wie sich eine gesamte installierte Basis zu einem bestimmten Zeitpunkt auf Releases, Länder und Endungen verteilt und welche dieser Websites die weiteren Technologien einsetzen, die eine Kontaktaufnahme lohnend machen würden.