Wer kontrolliert den fremden Code auf Ihrer Website?

Ein Chat-Widget, ein Analyse-Tool, ein Consent Manager, ein A/B-Test, ein eingebetteter Kalender: Viele Websites laden heute mehr fremden Code als das eigene Team bewusst überblickt.

Das Problem beginnt selten mit einem offensichtlich unseriösen Anbieter. Es beginnt mit einem Script, das „nur kurz“ eingebaut wurde – und Monate später weiterhin auf jeder Seite läuft, Daten überträgt, Performance kostet oder ausfällt, obwohl niemand mehr weiß, wer dafür verantwortlich ist.

Fremder JavaScript-Code ist kein neutrales Zubehör

Ein extern geladenes Script läuft im Kontext Ihrer Website. Je nach Einbindung kann es Inhalte lesen oder verändern, Formulare beobachten, zusätzliche Requests auslösen und weitere Ressourcen nachladen. Wird der Drittanbieter kompromittiert oder ändert sich sein Script unerwartet, tragen Ihre Besucher das Risiko mit.

Subresource Integrity, kurz SRI, erlaubt Browsern, extern geladene Scripts und Stylesheets gegen einen erwarteten kryptografischen Hash zu prüfen. Passt der Inhalt nicht mehr, wird die Ressource blockiert. Das schützt allerdings nur statische Dateien, deren Inhalt bewusst auf eine Version festgelegt werden kann.

Eine Content Security Policy ergänzt diese Kontrolle. Über script-src lässt sich festlegen, aus welchen Quellen JavaScript geladen werden darf. Eine CSP ist jedoch kein Zauberschalter: Eine großzügige Liste aus Dutzenden Domains dokumentiert eher das Problem, als es zu lösen.

Die eigentliche Schwachstelle ist fehlende Eigentümerschaft

Bei Audits sehen wir häufig dieselben Muster:

• Der Tag Manager enthält alte Tags, die niemand löschen möchte.
• Marketing, Agentur und Entwicklung können jeweils neue Scripts einbauen.
• Ein Script ist im Quellcode entfernt, wird aber weiterhin über den Consent Manager injiziert.
• Test- und Produktionsumgebungen laden unterschiedliche Anbieter.
• Die Datenschutzerklärung nennt Dienste, die technisch nicht mehr existieren – oder umgekehrt.
• Ein blockiertes Drittanbieter-Script legt Navigation, Checkout oder Formulare lahm.
• Niemand kann erklären, welche Geschäftsentscheidung hinter einer externen Domain steht.

Das ist gleichzeitig ein Sicherheits-, Datenschutz-, Performance- und Betriebsproblem.

Ein pragmatisches Drittanbieter-Inventar

Für jede externe Ressource sollten mindestens diese Angaben dokumentiert sein:

1. Anbieter und Domain: Wer liefert den Code tatsächlich aus?
2. Zweck: Welche konkrete Funktion rechtfertigt die Einbindung?
3. Eigentümer: Wer entscheidet über Änderungen und Entfernung?
4. Ladebedingung: Sofort, nach Einwilligung oder erst nach Nutzerinteraktion?
5. Datenfluss: Welche Requests, Identifikatoren oder Formulardaten können übertragen werden?
6. Ausfallverhalten: Funktioniert die Website weiter, wenn der Anbieter nicht erreichbar ist?
7. Technische Kontrolle: Selbst gehostet, feste Version, SRI, CSP, Sandbox oder keine Begrenzung?
8. Prüfdatum: Wann wurde die Notwendigkeit zuletzt bestätigt?

Dieses Inventar muss nicht mit einem teuren Governance-Produkt beginnen. Eine versionierte Tabelle im Repository ist besser als Wissen, das nur in Köpfen oder alten Tickets existiert.

Schnelltest im Browser

Öffnen Sie die Entwicklerwerkzeuge und laden Sie eine typische Seite neu. Filtern Sie im Netzwerk-Tab nach JS, und notieren Sie alle Domains, die nicht zu Ihrer Website gehören.

Prüfen Sie anschließend:

• Taucht jede Domain im Inventar auf?
• Ist klar, wodurch sie geladen wird?
• Wird sie vor einer erforderlichen Einwilligung angefragt?
• Lädt sie weitere unbekannte Domains nach?
• Was passiert, wenn Sie die Domain lokal blockieren?
• Gibt es doppelte Analyse- oder Marketing-Tags?
• Enthält Ihre CSP genau die Quellen, die wirklich benötigt werden?
• Können statische CDN-Ressourcen mit SRI abgesichert oder selbst gehostet werden?

Wiederholen Sie den Test für Startseite, Kontaktformular, Checkout, eingebettete Medien und eingeloggte Bereiche. Drittanbieter-Code ist häufig nicht überall identisch.

Performance ist ebenfalls Teil der Rechnung

Jedes zusätzliche Script konkurriert um Netzwerk, CPU-Zeit und den Hauptthread. Selbst ein kleines Tag kann weitere Bibliotheken, Fonts, Pixel oder Konfigurationsdateien laden. Die relevante Frage lautet daher nicht nur: „Wie groß ist diese Datei?“, sondern: „Welche Kette startet sie danach?“

Besonders kritisch sind Scripts, die synchron laden, Rendering blockieren, lange Tasks erzeugen oder auf langsame Drittanbieter-Endpunkte warten. Ein Anbieter kann die eigenen Server optimieren und trotzdem Ihre Conversion verschlechtern.

Was Website-Pflichtencheck prüfen würde

Ein Drittanbieter-Audit vergleicht den tatsächlich ausgelieferten Code mit Consent-Konfiguration, Datenschutzhinweisen und technischer Verantwortung. Wir prüfen externe Domains, Ladezeitpunkte, Tag-Manager-Regeln, doppelte Integrationen, Fehlerverhalten, CSP, mögliche SRI-Nutzung, Performance-Kosten und die Frage, ob kritische Funktionen auch bei einem Drittanbieter-Ausfall nutzbar bleiben.

Das Ziel ist nicht, jedes externe Tool zu verbieten. Das Ziel ist, aus zufällig gewachsenem Fremdcode eine bewusst kontrollierte Abhängigkeit zu machen.

Können Sie für jede fremde Domain auf Ihrer Website heute Zweck, Eigentümer und Ausfallverhalten nennen? Falls nicht, ist ein Inventar der sinnvollste erste Schritt – bevor das nächste entfernte Marketing-Tag zum Sicherheits- oder Umsatzproblem wird.