Wissen / Webentwicklung

Drittanbieter-Code: Was eine Website wirklich mitlädt.

Kurz gesagt: Externe Skripte können Funktionen schnell ergänzen, holen aber fremden Code, Verbindungen und Zuständigkeiten in eine Website. Entscheidend ist nicht, jede Abhängigkeit zu vermeiden, sondern ihren Zweck, Datenfluss, Ausfallweg, Wartungsbedarf und Schutz zu kennen. Was keinen belegbaren Nutzen hat, sollte nicht unbemerkt Teil des Systems bleiben.

Veröffentlicht am 2. September 2026 / Redaktion: Ruhrstack / 10 Minuten Lesezeit

01 / INVENTUR

Jede eingebundene Funktion bringt eine Zuständigkeit mit.

Ein sichtbares Widget kann im Hintergrund mehrere Server, Skripte und Unterabhängigkeiten erreichen.

Eine Website besteht selten nur aus selbst geschriebenem HTML, CSS und JavaScript. Schriften, Karten, Videos, Analysewerkzeuge, Consent-Systeme, Chats, Formulare, Bibliotheken und das CMS können von weiteren Anbietern stammen. Manche Ressourcen werden direkt aus einem fremden Netz geladen. Andere liegen auf dem eigenen Server, wurden aber als Paket übernommen. Wieder andere laufen nur beim Entwickeln und erreichen den Browser nie.

Diese Unterschiede entscheiden über das Risiko. Ein extern geladenes Skript kann sich ändern, ohne dass eine neue Websiteversion veröffentlicht wird. Eine lokal gespeicherte Bibliothek verändert sich nicht von allein, muss dafür aber bewusst aktualisiert werden. Ein Buildwerkzeug kann die ausgelieferte Datei beeinflussen, obwohl es für Besucher unsichtbar bleibt. Eine vollständige Betrachtung beginnt deshalb mit der Frage, wo Code herkommt, wann er ausgeführt wird und wer ihn pflegt.

Der Zweck gehört in dieselbe Liste. „Marketing“ oder „Plugin“ ist zu ungenau. Ein Eintrag sollte erklären, ob eine Ressource einen Termin bucht, ein Video abspielt, Fehler meldet oder Besuchsdaten übermittelt. Erst mit einem klaren Nutzen lässt sich entscheiden, ob Ladezeit, Datenfluss und Wartung angemessen sind. Was niemand mehr fachlich erklären kann, ist ein Kandidat für eine genauere Prüfung.

Das Ergebnis muss kein hundertseitiges Verzeichnis sein. Für eine kleine Unternehmenswebsite genügt oft eine gepflegte Tabelle aus Name, Ursprung, Zweck, übermittelten Daten, kritischer Funktion, Version, verantwortlicher Person und Aktualisierungsweg. Diese Inventur ist kein Sicherheitsnachweis. Sie schafft die Voraussetzung, um Änderungen und Vorfälle überhaupt zuordnen zu können.

02 / ARTEN

Laufzeit, Quellcode und Entwicklungswerkzeug sind getrennte Ebenen.

Der Sammelbegriff Drittanbieter-Code verdeckt sonst, welche Kontrolle und welcher Aktualisierungsweg tatsächlich bestehen.

Drei Ebenen mit unterschiedlicher Wirkung
Ebene	Beispiel	Zentrale Prüffrage
Externe Laufzeitressource	Chat, Karte oder Skript von einem fremden Ursprung	Was kann der Anbieter im Browser lesen, ändern oder nachladen?
Lokal ausgelieferte Abhängigkeit	CMS-Erweiterung, Bibliothek oder Schriftdatei	Wer prüft und installiert notwendige Aktualisierungen?
Entwicklungsabhängigkeit	Buildwerkzeug, Testpaket oder Deployment-Integration	Kann sie erzeugte Dateien oder Veröffentlichungszugänge beeinflussen?

Ein Content Delivery Network, kurz CDN, beschreibt zunächst nur eine verteilte Auslieferungsinfrastruktur. Es sagt nicht, ob eine Datei vertrauenswürdig, datenschutzgerecht oder aktuell ist. Ein eigener CDN-Ursprung kann unter Unternehmenskontrolle stehen; ein öffentliches CDN kann von einem Dritten betrieben werden. Entscheidend ist der konkrete Betreiber und die Art der Einbindung.

Auch „Plugin“ ist keine einheitliche Risikoklasse. Eine serverseitige Erweiterung kann Datenbank und Dateisystem erreichen. Ein Browser-Widget sieht möglicherweise den DOM und Eingaben auf der Seite. Ein kleines Buildplugin läuft mit Berechtigungen in der Entwicklungsumgebung. Umfang und Position im System sind wichtiger als die sichtbare Größe der Funktion.

Direkte Abhängigkeiten werden bewusst ausgewählt. Transitive Abhängigkeiten kommen über andere Pakete hinzu. Eine einzige Bibliothek kann damit eine längere Kette erzeugen. OWASP nennt das Verständnis und die fortlaufende Überwachung dieser Beziehungen als Grundlage der Lieferkettensicherheit. Weniger Pakete können die Übersicht erleichtern, doch Anzahl allein bewertet weder Qualität noch Wartung.

03 / RISIKEN

Fremdes JavaScript arbeitet im Vertrauensraum der Seite.

OWASP trennt Kontrollverlust, Codeausführung und mögliche Datenweitergabe als wesentliche Risikobereiche.

Ein direkt eingebundenes Drittanbieter-Skript wird im Browser der Besucher ausgeführt. Es kann die Dokumentstruktur lesen und verändern, weitere Anfragen senden und auf Informationen zugreifen, die in seinem Ausführungskontext verfügbar sind. OWASP weist darauf hin, dass fremder Code damit weitreichende Rechte erhalten kann. Eine kleine script-Zeile im HTML beschreibt nicht den Umfang dessen, was anschließend geladen wird.

Kontrollverlust entsteht, wenn der Anbieter die ausgelieferte Datei verändert. Eine neue Funktion, ein Fehler oder ein kompromittiertes System kann die eigene Seite beeinflussen, ohne dass deren Betreiber aktiv veröffentlicht hat. Tag Manager erhöhen diese Dynamik, weil berechtigte Personen zusätzliche Tags über eine Oberfläche ausrollen können. Das kann organisatorisch nützlich sein, verlangt aber geregelte Rollen, Freigaben und eine aktuelle Bestandsliste.

Datenweitergabe beginnt bereits mit einer Anfrage an einen fremden Ursprung. Der Betreiber kann technische Verbindungsdaten erhalten; ein Skript kann je nach Implementierung weitere Seiten- oder Interaktionsdaten übertragen. Welche Verarbeitung zulässig ist, ist eine rechtliche und organisatorische Frage und wird hier nicht pauschal beantwortet. Technisch muss jedoch bekannt sein, welche Verbindung wann entsteht. Ohne diese Kenntnis kann auch eine Einwilligungsentscheidung nicht verlässlich umgesetzt werden.

Das Risiko rechtfertigt kein pauschales Verbot. Ein etablierter Zahlungs-, Karten- oder Videodienst kann eine Aufgabe besser erfüllen als eine ungeprüfte Eigenentwicklung. Die Entscheidung braucht nur einen benannten Zweck, eine fachliche Prüfung und einen Plan für Änderungen. Ein externer Anbieter wird damit als Teil des Systems behandelt, nicht als unsichtbarer Codeausschnitt.

04 / WIRKUNG

Jede fremde Verbindung kann Laden und Bedienung verändern.

Performanceprobleme entstehen nicht nur durch Dateigröße, sondern auch durch zusätzliche Verbindungen, Ausführung und unkontrollierte Folgeanfragen.

Bevor eine Ressource von einem neuen Ursprung geladen wird, fallen unter anderem Namensauflösung, Verbindungsaufbau und sichere Aushandlung an. Das Skript muss anschließend übertragen, verarbeitet und ausgeführt werden. Es kann weitere Dateien, Bilder oder Netzwerkziele nachladen. Ein asynchron eingebundenes Skript blockiert vielleicht nicht den HTML-Parser, kann aber weiterhin den Hauptthread beanspruchen und die Reaktion auf Eingaben verzögern.

web.dev empfiehlt deshalb, Drittanbieter nach messbarem Nutzen und tatsächlichen Kosten zu beurteilen. Entwicklerwerkzeuge können Netzwerk, Ausführungsdauer und blockierende Aufgaben sichtbar machen. Ein Test mit gesperrtem Drittanbieter-Ursprung zeigt zusätzlich, ob die Hauptseite bei einem Ausfall noch funktioniert. Der Vergleich sollte unter gedrosseltem Netz und schwächerer CPU erfolgen, nicht nur auf einem schnellen Entwicklungsrechner.

Ein fremdes Widget kann außerdem zum einzelnen Ausfallpunkt werden. Reagiert sein Server langsam, darf die zentrale Leistungsbeschreibung nicht verschwinden. Ein Terminmodul kann einen alternativen Kontaktweg benötigen. Ein Video darf die restliche Seite nicht am Laden hindern. Kritische und ergänzende Funktionen werden unterschiedlich behandelt.

Die vorhandenen Core-Web-Vitals-Grundlagen erklären, wie JavaScript und nachgeladene Elemente LCP, INP und CLS beeinflussen können. Drittanbieter sind dabei keine eigene Metrik. Sie werden über ihre Wirkung auf Laden, Interaktion und Stabilität gemessen. Ein schneller Anbieter kann sinnvoll sein; eine ungenutzte Integration bleibt auch dann unnötig.

05 / SELBSTHOSTING

Lokale Auslieferung tauscht Fremdkontrolle gegen eigene Pflege.

Selbsthosting kann Verbindungen reduzieren und Versionen festhalten. Aktualisierungen werden dadurch nicht überflüssig.

Wird eine erlaubte Bibliothek auf dem eigenen Server ausgeliefert, kontrolliert der Websitebetreiber den Ursprung und den Veröffentlichungszeitpunkt. Eine fremde Laufzeitverbindung kann entfallen. Caching und Sicherheitsrichtlinien lassen sich gemeinsam mit den übrigen Ressourcen steuern. Diese Vorteile sind real, aber sie lösen nur einen Teil der Aufgabe.

Die lokale Datei erhält keine automatische Sicherheitskorrektur. Eine verantwortliche Person muss verfolgen, ob das Projekt gepflegt wird, welche Version eingesetzt ist und wann ein Update nötig wird. Lizenzbedingungen gelten ebenfalls weiter. Wird eine veraltete Kopie jahrelang vergessen, hat die zusätzliche Kontrolle ihren Zweck verfehlt. web.dev warnt ausdrücklich vor dieser Seite des Selbsthostings.

Manche Dienste lassen sich nicht sinnvoll lokal spiegeln. Eine Karte, ein Zahlungsdienst oder eine aktuelle externe Datenquelle benötigt die Verbindung zum Anbieter. Dann geht es um Begrenzung: Das Werkzeug wird nur dort geladen, wo es gebraucht wird; ein Platzhalter verhindert überraschende Anfragen; ein iframe kann Inhalt vom Hauptdokument trennen; und ein verständlicher Ersatzweg bleibt verfügbar.

Die Entscheidung ist daher nicht „CDN oder sicher“. Sie lautet: Welche Ressource erfüllt welchen Zweck, welche Kontrolle wird benötigt und welcher Aktualisierungsweg ist dauerhaft realistisch? Ein zentral gepflegter externer Dienst kann sicherer sein als eine vergessene lokale Kopie. Eine kleine lokale Datei kann robuster sein als eine unnötige fremde Verbindung. Kontext entscheidet.

06 / SCHUTZ

Technische Schutzmaßnahmen haben jeweils eine enge Aufgabe.

CSP, SRI, Sandbox und verzögertes Laden ergänzen eine gute Auswahl. Sie verwandeln eine ungeprüfte Integration nicht in eine sichere.

Content Security Policy: Eine Richtlinie, die festlegt, von welchen Ursprüngen eine Seite bestimmte Ressourcen laden oder ausführen darf. Das W3C beschreibt CSP als zusätzliche Verteidigung, nicht als Ersatz für sichere Eingabe- und Ausgabebehandlung.
Subresource Integrity: Ein Integritätswert für geeignete externe Ressourcen. Der Browser vergleicht den gelieferten Inhalt mit dem erwarteten kryptografischen Hash und verweigert eine nicht passende Ressource.
iframe-Sandbox: Eine Begrenzung für eingebettete Dokumente. Nur tatsächlich benötigte Fähigkeiten sollten freigegeben werden; die fachliche Prüfung des eingebetteten Dienstes bleibt nötig.
async und defer: Attribute, die das Herunterladen und Ausführen klassischer Skripte gegenüber dem HTML-Parsing steuern. Sie reduzieren bestimmte Blockaden, beseitigen aber weder Ausführungszeit noch Datenfluss.
Permissions Policy: Eine Richtlinie, mit der Browserfunktionen für die eigene Seite und eingebettete Inhalte begrenzt werden können.

SRI eignet sich nicht für jede dynamisch wechselnde Integration. Wenn der Anbieter die Datei aktualisiert, stimmt der festgelegte Hash nicht mehr und der Browser lädt sie nicht. Das kann genau der gewünschte Schutz sein, erfordert aber einen abgestimmten Aktualisierungsprozess. Die aktuelle W3C-Spezifikation ist zudem als Working Draft veröffentlicht; Aussagen zu einzelnen Ressourcentypen müssen am aktuellen Stand geprüft werden.

CSP kontrolliert erlaubte Quellen und kann unerwünschte Ausführung erschweren. Eine weit gefasste Freigabe für viele Domains schwächt diese Kontrolle. Gleichzeitig darf eine zu enge Richtlinie notwendige Funktionen nicht still blockieren. Einführung und Änderung benötigen deshalb einen Test der tatsächlichen Seite und ihrer Fehlerberichte.

Entfernen. Eine Funktion ohne belegten Nutzen erzeugt ohne Code die kleinste Angriffs- und Wartungsfläche.
Begrenzen. Ressource nur auf benötigten Seiten und möglichst spät laden.
Kapseln. Fremde Inhalte mit angemessener Sandbox und Berechtigungsrichtlinie trennen.
Prüfen. Herkunft, Version, Integrität und Datenfluss dokumentieren.
Überwachen. Ausfälle, Richtlinienverletzungen und bekannte Schwachstellen in den Betrieb aufnehmen.

07 / LIEFERKETTE

Die Software-Lieferkette beginnt vor der veröffentlichten Seite.

Quellcode, Pakete, Buildwerkzeuge, Versionsverwaltung und Deployment können die ausgelieferte Website beeinflussen.

NIST beschreibt den Secure Software Development Framework als Sammlung grundlegender Praktiken für vorbereitete Organisationen, geschützte Softwarebestandteile, sicher entwickelte Veröffentlichungen und die Reaktion auf verbleibende Schwachstellen. Der Ansatz ist risikobasiert und soll an Aufgabe, Kosten und Machbarkeit angepasst werden. Er ist keine starre Checkliste, die jede kleine Website in denselben Prozess zwingt.

Für Webprojekte beginnt ein angemessener Ablauf mit kontrollierter Versionsverwaltung und bekannten Quellen. Paketversionen werden nachvollziehbar festgehalten. Lockdateien helfen, dieselbe aufgelöste Abhängigkeitsstruktur wiederherzustellen, ersetzen aber keine Bewertung oder Aktualisierung. Veröffentlichungszugänge erhalten nur notwendige Rechte. Geheimnisse gehören nicht in öffentliches Quellmaterial.

Eine Komponentenliste kann als einfache Inventur oder bei größeren Systemen als maschinenlesbare Software Bill of Materials geführt werden. Sie beantwortet, welche Version von einer gemeldeten Schwachstelle betroffen sein könnte. Danach braucht es einen Reaktionsweg: Wer bewertet die Meldung, wer testet ein Update, wann wird veröffentlicht und wie kann bei einem Fehler zurückgegangen werden?

Auch Entwicklungsplugins und Automatisierungen gehören in den Umfang. Ein kompromittiertes Paket muss nicht im Browser landen, um Schaden zu verursachen; es kann Quellcode, Zugangsdaten oder erzeugte Dateien beeinflussen. Die richtige Tiefe folgt dem Risiko. Eine kleine statische Präsenz braucht keinen Prozess wie eine Zahlungsplattform, aber auch sie profitiert von bekannten Werkzeugen, begrenzten Rechten und einer reproduzierbaren Veröffentlichung.

08 / ENTSCHEIDUNG

Jede Abhängigkeit braucht einen belegbaren Platz im System.

Behalten, lokal ausliefern, begrenzen, ersetzen oder entfernen sind fachliche Entscheidungen, keine Glaubenssätze.

Die Prüfung beginnt beim Nutzerwert. Löst die Integration eine Aufgabe, die tatsächlich gebraucht wird? Danach folgen technische und betriebliche Fragen. Welche Daten erreichen welchen Anbieter? Was passiert bei einem Ausfall? Wie groß ist die Wirkung auf Laden und Interaktion? Wer verfolgt Updates? Gibt es einen einfacheren Weg mit vergleichbarem Nutzen?

Vom Befund zur begründeten Maßnahme
Befund	Mögliche Entscheidung	Danach prüfen
Klarer Nutzen, kontrollierbares Risiko	Behalten und dokumentieren	Version, Datenfluss, Ausfall und Wartung
Nützliche statische Ressource	Lokale Auslieferung prüfen	Lizenz und eigener Aktualisierungsweg
Ergänzende externe Funktion	Später laden oder kapseln	Fallback, Sandbox und Berechtigungen
Doppelte oder nicht mehr genutzte Funktion	Kontrolliert entfernen	Abhängige Seiten und Messung
Unklarer Betreiber oder keine Pflege	Alternative suchen	Migration, Daten und Vertragsende

Eine Änderung wird nicht nur an einer Startseite geprüft. Ein entferntes Skript kann Kontaktformulare, Unterseiten oder Consent-Zustände beeinflussen. Browser- und Geräteprüfung, Tastaturbedienung, Performance und Fehlerkonsole gehören zur Abnahme. Danach wird die Inventur aktualisiert. Sonst beginnt die nächste Prüfung wieder bei Vermutungen.

Die Entscheidung kann auch lauten, eine Abhängigkeit bewusst zu akzeptieren. Transparenz bedeutet nicht, jede technische Beziehung zu vermeiden. Sie bedeutet, dass Nutzen, Grenze und Verantwortung benannt sind. Genau dadurch bleibt die Website später übernehmbar.

09 / RUHRSTACK

Ruhrstack betrachtet Code, Betrieb und Zuständigkeit gemeinsam.

Eine kleine Integration kann Website, Hosting, Sicherheit und Performance gleichzeitig berühren.

Bei der Website-Konzeption und Entwicklung wählt Ruhrstack CMS, statische Umsetzung oder individuelle Entwicklung nach Bearbeitungsbedarf, Funktionen und Wartbarkeit. „Ohne unnötige technische Schichten“ bedeutet nicht, bewährte Bibliotheken grundsätzlich auszuschließen. Es bedeutet, dass jede Schicht eine Aufgabe übernimmt und später verständlich gepflegt werden kann.

Hosting und Betrieb betreffen Ursprünge, Caching, Backups und die Verfügbarkeit eingebundener Dienste. Die Sicherheitsleistung ordnet Komponenten, Zugänge, Konfiguration und Aktualität ein. SEO und Performance prüfen, ob Drittcode das Laden, die Interaktion oder die crawlbare Hauptaussage beeinträchtigt. Eine Abhängigkeitsinventur verbindet diese Perspektiven.

Für eine erste Einordnung genügt eine bestehende URL und die Funktion, um die es geht. Der sichtbare Netzwerkverkehr und der Codebestand zeigen anschließend, welche Anbieter und Ressourcen beteiligt sind. Zugangsdaten gehören nicht in die erste Nachricht. Wenn eine tiefere Prüfung nötig ist, werden Umfang und sichere Übergabe vorher abgestimmt.

Der Beitrag Website-Sicherheit als Zusammenspiel vertieft Updates, Backups, TLS und CSP. Die HTML-first-Grundlagen zeigen ergänzend, wann die native Webplattform eine zusätzliche Bibliothek ersetzen kann. Beide Entscheidungen bleiben projektspezifisch.

10 / KURZANTWORTEN

Vier häufige Fragen kurz beantwortet.

Zu CDNs, Selbsthosting, statischen Websites und kleinen Komponentenlisten.

Ist ein CDN grundsätzlich unsicher?

Nein. CDN bezeichnet eine Auslieferungsarchitektur, keine feste Sicherheitsqualität. Bewertet werden Betreiber, Ressource, Verbindung, Änderungskontrolle, Datenfluss und Ausfallverhalten. Für externe Skripte können CSP und SRI passende zusätzliche Kontrollen sein, ersetzen aber die Auswahl und Wartung nicht.

Macht Selbsthosting eine Website automatisch datenschutzkonform?

Nein. Lokale Auslieferung kann eine fremde Verbindung vermeiden, beantwortet aber nicht alle Fragen zur Datenverarbeitung der Website. Formulare, Serverprotokolle, eingebettete Dienste und organisatorische Abläufe bleiben relevant. Eine rechtliche Bewertung muss den konkreten Einsatz betrachten.

Ist eine statische Website automatisch sicher?

Nein. Eine kleinere Laufzeit kann bestimmte Angriffsflächen reduzieren, doch Hostingkonfiguration, Veröffentlichungszugänge, fremde Skripte, Formulare und Entwicklungswerkzeuge bleiben mögliche Risiken. Sicherheit entsteht aus begrenzter Technik, aktuellen Komponenten und einem geregelten Betrieb.

Braucht jede kleine Website eine formale SBOM?

Nicht zwingend. Die angemessene Dokumentation richtet sich nach Umfang und Risiko. Auch eine kleine Website sollte jedoch erkennen lassen, welche produktiven Bibliotheken, Plugins und externen Dienste sie verwendet, welche Versionen relevant sind und wer Aktualisierungen verantwortet.

11 / QUELLEN

Quellen und redaktioneller Stand.

Primärdokumentation von OWASP, NIST, W3C und web.dev zu Drittanbieter-Code, Lieferkette, Integrität, Richtlinien und Performance. Der Artikel wurde am 2. September 2026 veröffentlicht.

Redaktion: Ruhrstack, Dortmund
Veröffentlicht: 2. September 2026
Quellen geprüft: 2. September 2026

OWASP Cheat Sheet Series: Third Party JavaScript Management, abgerufen am 2. September 2026.
OWASP Cheat Sheet Series: Software Supply Chain Security, abgerufen am 2. September 2026.
National Institute of Standards and Technology: Secure Software Development Framework, abgerufen am 2. September 2026.
World Wide Web Consortium: Subresource Integrity, Working Draft, abgerufen am 2. September 2026.
World Wide Web Consortium: Content Security Policy Level 3, Working Draft vom 13. August 2026.
web.dev: Load Third-Party JavaScript, aktualisiert am 19. Februar 2024.
web.dev: Third parties and privacy, abgerufen am 2. September 2026.

Redaktioneller Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Einzelfallprüfung. Trotz sorgfältiger Recherche wird keine Gewähr für Vollständigkeit und fortdauernde Aktualität übernommen. Eine Haftung nach zwingenden gesetzlichen Vorschriften bleibt unberührt. Redaktionelle Einordnung.