Was Datenabfluss auf einer Website konkret bedeutet
Datenabfluss klingt nach Sicherheitsvorfall, ist aber zuerst der stille Normalbetrieb. Sobald eine Seite eine Schrift von einem fremden CDN lädt, eine Karte einbettet oder ein Analyse-Skript ausführt, verbindet sich der Browser des Besuchers direkt mit dem Server des Anbieters. Dabei wird nicht nur die gewünschte Datei geholt – der Anbieter erfährt zwangsläufig, wer wann welche Seite aufgerufen hat. Diese Verbindungen summieren sich schnell: Auf den 1.000 größten Websites liegt der Median bei 66 eingebundenen Drittanbietern (Web Almanac 2024). Auch abseits der Spitze ist die Zahl hoch, denn ein einziges Werbe- oder Consent-Skript zieht in der Regel weitere Endpunkte nach.
Der Punkt ist die Sichtbarkeit. Die meisten dieser Drittanbieter tauchen nirgends in einer Liste auf, sondern kommen aus einem Theme, einem Plugin, einem Tag-Manager oder werden erst zur Laufzeit nachgeladen. Dass 45 % aller Requests einer durchschnittlichen Seite an Dritte gehen (Web Almanac 2024), heißt: Fast jeder zweite Verbindungsaufbau verlässt die eigene Domain – und mit ihm ein Stück Besucherdaten. Solange niemand diese Flüsse erfasst, bleibt der halbe Datenverkehr der eigenen Seite eine Blackbox. Wie stark einzelne Fremdskripte zusätzlich Sicherheit und Tempo belasten, ordnet der Beitrag zum Risiko von Third-Party-Skripten ein.
Warum jeder Drittanbieter-Request personenbezogene Daten überträgt
Kein HTTP-Request ist leer. Schon der schlichte Abruf einer Schriftdatei sendet an den Zielserver die IP-Adresse des Besuchers, den User-Agent (Browser, Version, Betriebssystem), die aufrufende Seite als Referer sowie je nach Kontext gesetzte Cookies. Das ist keine Nebensache: Der Europäische Gerichtshof hat bereits entschieden, dass auch dynamische IP-Adressen personenbezogene Daten sein können (EuGH, Rechtssache C-582/14, Breyer). Damit fällt jeder solche Request unter die Datenschutz-Grundverordnung – unabhängig davon, ob der Anbieter die Daten weiterverwendet oder nur im Log stehen lässt.
Entscheidend ist die Rechtsgrundlage. Nicht-notwendige Einbindungen, die Kennungen setzen oder auslesen, verlangen nach deutschem Recht eine vorherige Einwilligung (TDDDG, § 25). Fehlt sie, findet der Datenabfluss vor dem Consent statt – der klassische Fall, der bei Prüfungen auffällt. Ob Skripte trotz fehlender oder widerrufener Einwilligung feuern, ist ein eigenes Überwachungsthema, das der Beitrag zum Consent-Tag-Drift vertieft.
Auch ohne Cookies sendet der Browser bei jedem Drittanbieter-Aufruf: die IP-Adresse (laut EuGH ein potenziell personenbezogenes Datum, Rechtssache C-582/14), den User-Agent mit Browser- und Systemkennung, den Referer mit der aufgerufenen URL, die Sprach- und Zeitzoneneinstellung sowie technische Header. In Summe entsteht daraus ein wiedererkennbarer Fingerabdruck – und der Zielserver kennt den Zeitpunkt und die Seite des Besuchs. Genau diese Metadaten fließen ab, lange bevor irgendein Tracking-Cookie ins Spiel kommt.
Das Drittland-Problem: warum die USA seit Schrems II heikel sind
Fließen die Daten an einen Host innerhalb der EU, gelten die vertrauten Regeln der DSGVO. Verlassen sie den europäischen Wirtschaftsraum, wird es komplizierter. Am 16. Juli 2020 hat der Europäische Gerichtshof mit dem sogenannten Schrems-II-Urteil das EU-US-Datenschutzabkommen Privacy Shield für ungültig erklärt (EuGH, Rechtssache C-311/18). Seither ist jeder Transfer personenbezogener Daten in die USA rechtlich prüfpflichtig. Die Datenschutzorganisation noyb reichte in der Folge 101 Musterbeschwerden gegen Unternehmen ein, die weiterhin Daten in die USA übermittelten (noyb). Der Rahmen dafür steht in Kapitel V der DSGVO: Ein Drittlandtransfer braucht eine eigene Rechtsgrundlage (DSGVO, Art. 44 ff.), etwa Standardvertragsklauseln (DSGVO, Art. 46).
Seit dem 10. Juli 2023 gibt es mit dem EU-US Data Privacy Framework wieder einen Angemessenheitsbeschluss der Europäischen Kommission (EU-Kommission). Er entschärft die Lage, löst sie aber nicht vollständig: Er greift nur für US-Unternehmen, die sich aktiv unter dem Framework zertifiziert haben und auf der offiziellen Liste stehen (EU-Kommission). Ein Ziel-Host allein sagt darüber nichts aus. Mehrere europäische Aufsichtsbehörden hatten den unkontrollierten US-Transfer zuvor als unzulässig eingestuft – die österreichische Datenschutzbehörde etwa bewertete den Einsatz eines weit verbreiteten US-Reichweiten-Analysediensts 2022 als Verstoß gegen die DSGVO (österreichische Datenschutzbehörde), die französische CNIL kam kurz darauf zum selben Schluss (CNIL). Wer heute misst, muss also nicht nur wissen, dass Daten in die USA fließen, sondern auch, an wen und auf welcher Grundlage.
Die folgende Übersicht zeigt, wie ein Ziel-Host nach Land und Einstufung klassifiziert wird. Die Beispiel-Hosts sind generisch; entscheidend ist das Muster, nach dem ein Audit jeden Fluss einsortiert.
| Kategorie | Ziel-Host (Beispiel) | Land | Einstufung |
|---|---|---|---|
| Web-Schriften (CDN) | fonts-cdn.example.net | USA | Drittland-Transfer |
| Tag- / Consent-Manager | tags.example-mkt.com | USA | Drittland-Transfer |
| Karten- / Geodienst | maps.example-geo.com | USA | Drittland-Transfer |
| Reichweitenmessung (self-hosted) | static.eigene-domain.de | Deutschland | Erstanbieter |
| Auslieferung (EU-CDN) | cdn.example-eu.de | EU | EU-intern |
Aus der Tabelle wird der Kern der Aufgabe sichtbar: Nicht jeder Drittanbieter ist ein Problem, aber jeder Drittland-Transfer braucht eine bewusste Entscheidung. Ein prominenter Fall ist die eingebettete Web-Schrift – wie daraus eine abmahnfähige Übermittlung wird, beschreibt der Beitrag zu Google Fonts und der DSGVO.
Rechtliche Folgen eines unbemerkten Datenabflusses
Ein unkontrollierter Datenabfluss ist kein theoretisches Risiko. Verstöße gegen die Transferregeln der DSGVO können mit Bußgeldern bis zu 20 Mio. Euro oder 4 % des weltweiten Jahresumsatzes geahndet werden (DSGVO, Art. 83). Hinzu kommt die Abmahnrealität in Deutschland: Das Landgericht München I sprach einem Websitebesucher 100 Euro Schadensersatz zu, weil eine Seite Google Fonts von einem US-Server nachlud und dabei seine IP-Adresse ohne Einwilligung übermittelte (LG München I, Az. 3 O 17493/20). Nach diesem Urteil folgten bundesweit Abmahnwellen wegen genau desselben, unscheinbaren Datenabflusses.
Die Sicherheitsseite kommt hinzu. Drittanbieter-Einbindungen sind zugleich Teil der Lieferkette einer Website: Ein kompromittierter externer Endpunkt kann Eingaben abgreifen oder Skript einschleusen. Im Verizon Data Breach Investigations Report war zuletzt jeder siebte Sicherheitsvorfall – rund 15 % – mit einem Drittanbieter verknüpft, ein Anstieg um 68 % gegenüber dem Vorjahr (Verizon DBIR 2024). Wer nicht weiß, welche fremden Hosts die eigene Seite kontaktiert, kann diese Angriffsfläche weder eingrenzen noch überwachen.
Ein Drittanbieter mit sauberer Rechtsgrundlage ist völlig in Ordnung. Riskant ist der Fluss, von dem niemand weiß – die Schrift aus einem US-CDN, die ein Theme mitbringt, das Pixel, das ein Kampagnen-Tag nachlädt, der Kartendienst auf der Kontaktseite. Wer diese Ziele kennt, kann bewusst entscheiden: selbst hosten, ersetzen, absichern oder mit dokumentierter Rechtsgrundlage belassen. Ohne diese Kenntnis fällt die Entscheidung jeden Tag stillschweigend gegen den Datenschutz aus.
Datenabfluss messen: der Netzwerk-Request-Audit
Der erste Schritt ist kein Großprojekt, sondern eine Messung. Der Compliance-Check und Security-Scan rendert die Seite in einem echten Browser und protokolliert jeden ausgehenden Request – genau so, wie ihn der Browser eines Besuchers auslöst. Anschließend wird jeder Ziel-Host aufgelöst und einem Land zugeordnet. Das Ergebnis ist die Darstellung aus dem Mockup oben: die eigene Seite links, die Datenflüsse zu ihren Ziel-Hosts rechts, jeder mit Länderkürzel und einer klaren Markierung, ob er die EU verlässt. Dass 45 % der Requests an Dritte gehen (Web Almanac 2024), macht eine automatische Auswertung nötig – von Hand ist diese Menge nicht sauber zu erfassen.
Wichtig ist, dass die Messung im echten Rendering stattfindet und nicht nur im ausgelieferten HTML. Ein großer Teil der Flüsse entsteht erst zur Laufzeit: dynamisch nachgeladene Skripte, Weiterleitungen von einem Endpunkt zum nächsten, Einbindungen aus einem Tag-Manager. Nur wer sieht, was der Browser tatsächlich ausführt, erfasst auch diese Ziele. Vier Ebenen gehören in einen belastbaren Netzwerk-Request-Audit.
Jeden ausgehenden Netzwerk-Request im echten Browser-Rendering protokollieren – auch dynamisch nachgeladene und über Weiterleitungen entstehende Verbindungen, die im reinen Quelltext unsichtbar bleiben.
Zu jedem Request den tatsächlichen Ziel-Host bestimmen und von der eigenen Domain unterscheiden. Erst die Trennung von Erst- und Drittanbieter macht den eigentlichen Datenabfluss messbar.
Jeden Ziel-Host einem Land zuordnen und markieren, ob er innerhalb der EU liegt oder einen Drittland-Transfer auslöst. Aus einer Hostliste wird so eine datenschutzrechtlich lesbare Karte.
Eine einmalige Momentaufnahme veraltet mit dem nächsten Deploy. Erst die wiederkehrende Messung fängt neu hinzugekommene Ziele ab und meldet, wenn ein Fluss unbemerkt ein Drittland erreicht.
Zwei Unterscheidungen tragen den ganzen Audit. Erstens: Erstanbieter-Requests bleiben auf der eigenen Domain, Drittanbieter-Requests verlassen sie – nur Letztere sind ein Datenabfluss an einen fremden Verantwortlichen. Zweitens: Ein bekannter, dokumentierter Fluss mit Rechtsgrundlage ist etwas anderes als ein neu aufgetauchter, den niemand angeordnet hat. Deshalb geht es nicht darum, jeden Drittanbieter zu verbieten, sondern die Liste vollständig zu kennen und jede Änderung zu bemerken.
Vom Audit zur Entscheidung: welchen Fluss zuerst prüfen
Ein Audit findet erfahrungsgemäß mehr Flüsse, als man erwartet – bei einem Median von 66 Drittanbietern auf großen Seiten (Web Almanac 2024) ist das kein Wunder. Die Liste abzuarbeiten heißt nicht, alles heute Abend umzubauen. Eine kurze Reihenfolge nach Risiko führt schneller zum Ziel als blinder Aktionismus.
- Drittland-Transfer ohne Rechtsgrundlage zuerst. Ein Fluss in die USA oder ein anderes Drittland, für den weder Angemessenheitsbeschluss noch Standardvertragsklauseln vorliegen (DSGVO, Art. 44 ff.), gehört an die Spitze. Das ist der Fall, der bei Aufsicht und Abmahnung als Erstes auffällt.
- Pre-Consent-Flüsse als Nächstes. Feuert ein Ziel, bevor der Besucher eingewilligt hat, obwohl es der Einwilligung bedürfte (TDDDG, § 25), ist der Datenabfluss bereits geschehen. Solche Flüsse wiegen schwerer als ein Ziel, das erst nach aktiver Zustimmung lädt.
- Sensible Kontexte danach. Ein Drittanbieter in der Nähe von Formularen, Login oder Bezahlung ist heikler als derselbe auf einer statischen Unterseite. Ob ein Kontaktformular überhaupt zuverlässig zustellt, gehört an dieser Stelle mit auf den Prüfstand.
- Den Rest dokumentieren. Was eine saubere Rechtsgrundlage hat und nach Consent lädt, bleibt – aber schriftlich festgehalten, damit die Entscheidung nachvollziehbar ist. Diese Dokumentation ist zugleich Baustein einer Datenschutz-Folgenabschätzung für Web-Tracking.
Nach jedem Deploy neu messen
Ein einmaliger Audit sagt, wie die Seite heute sendet. Doch die Flüsse ändern sich mit jedem Release: Ein neues Plugin bringt ein Werbe-Pixel mit, ein Marketing-Team hängt ein Tag ein, ein Theme-Update tauscht ein CDN aus. Deshalb gehört die Messung nicht in ein jährliches Audit, sondern in die laufende Überwachung – idealerweise nach jedem Deploy. Bei 45 % Fremd-Requests im Durchschnitt (Web Almanac 2024) ist ein einzelner Neuzugang schnell übersehen.
Taucht ein neuer Drittland-Transfer auf, soll das nicht wochenlang unbemerkt bleiben. Ein Regressions-Alert über die konfigurierten Benachrichtigungskanäle meldet das neue Ziel, solange der Zusammenhang zum letzten Release noch frisch ist. Dieselbe Deploy-Logik greift bei benachbarten Risiken: bei einer neu eingeschleppten verwundbaren JavaScript-Bibliothek, bei einer steigenden 5xx-Serverfehlerrate nach einem Release oder bei zusätzlichem Übertragungsgewicht, das der Beitrag zum Page Weight und Resource Bloat behandelt. Auch die Datenqualität profitiert: Wer weiß, welche fremden Hosts eingebunden sind, trennt echten Traffic leichter von Referrer-Spam und Ghost-Traffic.
Der praktische Einstieg braucht keine große Vorbereitung: eine einzige Website scannen, die Liste der Ziel-Hosts ansehen, den ersten Drittland-Transfer einordnen. Mit hoher Wahrscheinlichkeit stellen Sie fest, dass die Liste länger ist als gedacht – und die wirklich dringenden Fälle an einer Hand abzuzählen sind. Das Zusammenspiel aus Audit, Klassifikation und Alert zeigt die Live-Demo; welche Funktion in welchem Tarif enthalten ist, steht in der Preisübersicht. Aus einem unsichtbaren Dauerabfluss wird so eine bewusste, wiederkehrende Entscheidung.
Dieser Artikel basiert auf Daten und Dokumenten von: Web Almanac 2024 (HTTP Archive) – Kapitel zu Third Parties: 92 % der Seiten mit mindestens einem Drittanbieter, 45 % aller Requests an Dritte, Median von 66 Drittanbietern auf den 1.000 größten Websites; Europäischer Gerichtshof – Schrems-II-Urteil vom 16.07.2020 (Rechtssache C-311/18, Ungültigkeit des Privacy Shield) und Breyer-Urteil zu IP-Adressen als personenbezogene Daten (Rechtssache C-582/14); noyb – 101 Musterbeschwerden zu EU-US-Datentransfers nach Schrems II; Europäische Kommission – Angemessenheitsbeschluss zum EU-US Data Privacy Framework vom 10.07.2023; DSGVO – Kapitel V (Art. 44 und Art. 46, Drittlandtransfer) und Art. 83 (Bußgeldrahmen bis 20 Mio. Euro oder 4 % des Jahresumsatzes); TDDDG – § 25 (Einwilligungspflicht für nicht-notwendige Einbindungen); LG München I – Urteil Az. 3 O 17493/20 (100 Euro Schadensersatz wegen Google-Fonts-Übermittlung); österreichische Datenschutzbehörde und CNIL – Entscheidungen 2022 zum unzulässigen US-Transfer per US-Analysedienst; Verizon Data Breach Investigations Report 2024 – rund 15 % der Vorfälle mit Drittanbieter-Beteiligung, Anstieg um 68 %.