Drittanbieter-Skripte — das versteckte Datenleck
Eine durchschnittliche Website lädt Skripte von einem Dutzend fremder Server: Tracking, Schriften, Karten, Chat-Widgets, Bewertungs-Sterne, Social-Buttons. Jedes dieser Skripte sieht den Besucher — seine IP, oft mehr — und jedes verzögert den Seitenaufbau. Auf einer Steuerkanzlei-Seite ist beides ein Problem: ein Datenschutz-Leck und ein Performance-Leck zugleich. Das Tückische ist, dass diese Skripte selten bewusst eingebaut wurden; sie kamen mit einem Theme, einem Plugin oder einem kopierten Einbettungs-Code. Dieser Artikel zeigt, wie man sie sichtbar macht und begrenzt.
Was Sie aus diesem Artikel mitnehmen
- Was ein Drittanbieter-Skript ist und warum jedes eines den Besucher sieht
- Warum externe Skripte den Seitenaufbau bremsen (render-blocking, fremde Verbindungen)
- Was ein „Drittanbieter-Inventar" ist und wie wir es im Audit erstellen
- Wie die Content-Security-Policy fremde Skripte technisch hart begrenzt
Würdigung — was ein Drittanbieter-Skript ist
Ein Drittanbieter-Skript ist Code, den die Website von einem fremden Server nachlädt und im Browser des Besuchers ausführt. Typische Beispiele: ein Analyse-Skript, ein eingebettetes Bewertungs-Widget, eine Chat-Box, ein Social-Media-Button, eine Karten-Einbettung. Jedes davon hat zwei Eigenschaften, die zusammen das Problem ausmachen: Es läuft mit den Rechten Ihrer Seite, und es kommuniziert mit einem fremden Server.
Das ist selten eine bewusste Entscheidung der Kanzlei. Die Skripte kommen als Default eines Themes, als Funktion eines Plugins oder als kopierter Einbettungs-Schnipsel. Niemand hat „Tracking durch fünf US-Dienste" angeklickt — es war einfach mit dabei. Genau deshalb ist der erste Schritt, überhaupt zu wissen, welche Skripte eine Seite lädt.
Hinweis:
Welche Drittanbieter Ihre Seite kontaktiert, listet unser kostenfreier URL-Audit in rund 90 Sekunden auf — das ist der Anfang jedes Drittanbieter-Inventars.
Das Datenschutz-Leck — jedes Skript sieht den Besucher
Sobald der Browser ein Skript von einem fremden Server lädt, sendet er an diesen Server eine Anfrage — mit IP-Adresse, oft mit Referrer (welche Seite gerade besucht wird) und weiteren technischen Daten. Bei vielen Diensten kommen Cookies oder Fingerprinting dazu. Für jeden dieser Abflüsse braucht es nach DSGVO eine Rechtsgrundlage, und für alles, was nicht technisch zwingend ist, nach § 25 TDDDG eine Einwilligung. Das ist der Mechanismus, der hinter dem Google-Fonts-Fall steht — und er gilt für jedes externe Skript, nicht nur für Schriften.
Für eine Kanzlei verschärft sich das: Ihre Seite steht unter dem Vertrauensanspruch des § 203 StGB. Ein Besucher, der die Mandanten-Frage auf der Kontaktseite liest und dabei von fünf US-Trackern erfasst wird, bekommt das falsche Signal. Eine cookielose, drittanbieter-arme Seite sendet das richtige.
Das Performance-Leck — render-blocking und fremde Verbindungen
Drittanbieter-Skripte kosten doppelt Zeit. Erstens muss der Browser für jeden fremden Server eine neue Verbindung aufbauen (DNS-Auflösung, TLS-Handshake) — bevor das Skript überhaupt geladen wird. Zweitens blockieren Skripte, die im Kopf der Seite stehen, oft den Seitenaufbau: Der Browser wartet, bis das Skript geladen und ausgeführt ist, bevor er weitermacht (render-blocking). Das verschlechtert den LCP-Wert der Core Web Vitals — und damit das Google-Ranking.
Das Bittere: Die Kanzlei trägt die Performance-Kosten für Funktionen, die sie oft gar nicht braucht. Ein Social-Button, den niemand klickt, ein Chat-Widget, das nie genutzt wird, ein Bewertungs-Skript, das auch als statischer Wert darstellbar wäre — alle drei bremsen jede einzelne Seite, für alle Besucher, dauerhaft.
Das Drittanbieter-Inventar — wie wir auditieren
Im Audit erstellen wir ein Drittanbieter-Inventar: eine Liste jeder externen Quelle, die die Seite kontaktiert, mit drei Spalten je Eintrag — welcher Dienst, welcher Zweck, welche Rechtsgrundlage bzw. Einwilligung. Diese schlichte Tabelle deckt regelmäßig auf, dass eine Seite Dienste lädt, von denen niemand mehr wusste: ein Tracking-Pixel aus einer alten Kampagne, eine Karte mit Tracking, ein Schrift-CDN.
Aus dem Inventar folgt die Entscheidung pro Eintrag: weglassen (wenn ungenutzt), ersetzen (durch eine cookielose oder selbst-gehostete Variante), oder behalten und sauber per Einwilligung absichern (wenn wirklich nötig). Die meisten Einträge fallen in die ersten beiden Kategorien — was die Seite gleichzeitig datensparsamer und schneller macht. Der häufigste Einzel-Befund in unseren Audits ist dabei der Meta-/Facebook-Pixel — ein eigenständiger Insight, der den Abmahn-Klassiker auseinandernimmt.
Wie die CSP fremde Skripte hart begrenzt
Die technische Absicherung gegen unkontrollierte Drittanbieter ist die Content-Security-Policy. Mit script-src und connect-src legt sie fest, von welchen Quellen überhaupt Skripte geladen und mit welchen Servern Verbindungen aufgebaut werden dürfen. Alles, was nicht auf der Liste steht, blockt der Browser.
Auf fahoch2.de ist diese Liste bewusst kurz: script-src und connect-src erlauben die eigene Domain und als einzige Fremd-Quelle das cookielose Cloudflare-Analytics. Würde sich über ein Update ein weiteres Drittanbieter-Skript einschleichen, würde die CSP es blockieren — und der Fehler fiele sofort auf, statt unbemerkt Daten abfließen zu lassen. Die CSP ist damit nicht nur Schutz vor Angriffen, sondern auch ein Wächter über das eigene Drittanbieter-Inventar.
Beispiel:
In URL-Audits oberfränkischer Kanzlei-Sites finden sich typische Drittanbieter-Inventare von acht bis zwölf externen Quellen — darunter Chat-Widgets, die niemand bedient, Karten-Embeds mit Tracking, fremd geladene Schrift-CDNs. Eine konsequente Bereinigung (Widget weg, Schrift selbst hosten, Karte als click-to-load) würde das Inventar auf eine einzige, cookielose Quelle schrumpfen lassen — die Ladezeit sänke messbar. Wer wissen will, was die eigene Seite lädt: ein Erstgespräch (30 Minuten, kostenfrei) ordnet das Inventar ein.
Für eine vollständige Bestandsaufnahme — Drittanbieter-Inventar, Datenschutz-Konformität, Performance-Hebel — empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).
Zusammenfassung
Jedes Drittanbieter-Skript sieht den Besucher (IP, Referrer, oft mehr) und bremst die Seite (fremde Verbindung, render-blocking). Beides trifft eine Kanzlei-Seite besonders, weil sie unter dem Vertrauensanspruch des § 203 StGB steht und weil Performance ins Google-Ranking einfließt. Die Skripte kommen meist unbemerkt über Theme oder Plugin — deshalb beginnt die Lösung mit einem Drittanbieter-Inventar, das jede externe Quelle samt Zweck und Rechtsgrundlage auflistet. Pro Eintrag wird dann entschieden: weglassen, ersetzen oder sauber absichern. Die Content-Security-Policy hält das Ergebnis fest und blockiert, was sich neu einschleichen will. Der erste Schritt ist immer: wissen, was die eigene Seite überhaupt lädt.
Quellen
- MDN — CSP: script-src — abgerufen 2026-05-29
- MDN — CSP: connect-src — abgerufen 2026-05-29
- Google web.dev — Largest Contentful Paint (render-blocking) — abgerufen 2026-05-29
- TDDDG § 25 — Schutz der Privatsphäre bei Endeinrichtungen — abgerufen 2026-05-29
- DSGVO Art. 6 — Rechtmäßigkeit der Verarbeitung (VO EU 2016/679) — abgerufen 2026-05-29
Disclaimer: Allgemeine fachliche Information zum Zeitpunkt der Veröffentlichung — keine Rechtsberatung im Einzelfall. Welche Rechtsgrundlage ein konkreter Drittanbieter braucht, gehört in die anwaltlich geprüfte Datenschutzerklärung.
Stand und rechtlicher Hinweis
- Erstveröffentlichung
- Letzte Aktualisierung
- Autor
- Alexander Mock
- Lesezeit
- 10 Minuten
Allgemeine Information, keine individuelle Beratung. Dieser Artikel beschreibt steuer-, berufs- oder webrechtliche Grundsystematik zum oben genannten Stand. Er ist nicht mandantenspezifisch und ersetzt keine individuelle Rechts-, Steuer- oder Anlage-Beratung im Sinne § 2 Rechtsdienstleistungsgesetz (RDG), § 1 Steuerberatungsgesetz (StBerG) oder § 34d/f Gewerbeordnung (GewO). Vor jeder konkreten Entscheidung wenden Sie sich an einen zugelassenen Steuerberater, Rechtsanwalt oder die jeweils zuständige Behörde.
Zitate aus amtlichen Werken. Gesetzes-Texte, Verwaltungsanweisungen (BMF-Schreiben) und Gerichts-Entscheidungen (BFH, BGH, BVerfG, EuGH) sind nach § 5 Urheberrechtsgesetz gemeinfrei. Zitiert wird jeweils mit Aktenzeichen und Entscheidungs- bzw. Schreibens-Datum. Aktualität der Rechtslage bitte vor Bezugnahme gegen die jeweilige amtliche Veröffentlichung prüfen (gesetze-im-internet.de, bundesfinanzhof.de, bmf.bund.de).
Externe Quellen. Wo wir auf Studien, Branchenstatistiken oder Drittanbieter-Dokumente verweisen, ist das Abrufs-Datum jeweils beim Quellenverweis angegeben. Online-Inhalte können sich nach unserem Abruf geändert haben.
Haftung. Trotz sorgfältiger Recherche können Ungenauigkeiten oder Rechtsänderungen nach Veröffentlichung nicht ausgeschlossen werden. Eine Haftung für Schäden, die durch die Nutzung der Information ohne anwaltliche oder steuerberaterliche Gegenprüfung entstehen, ist ausgeschlossen — soweit gesetzlich zulässig.
Themen
Auch zu lesen
Code & Architektur
Self-hosted Fonts mit next/font — der DSGVO-Fall gelöst
Schriftarten sind das unscheinbarste Datenschutz-Problem im Web — und eines der am häufigsten abgemahnten. Wer Google Fonts auf die übliche Art einbindet, lädt sie bei jedem Seitenaufruf von Googles Servern. Dabei wandert die IP-Adresse des Besuchers an Google in die USA, ohne Einwilligung. Das LG München I hat dafür Schadenersatz zugesprochen. Die Lösung ist technisch unspektakulär und beseitigt das Problem an der Wurzel: die Schriften selbst hosten. Dieser Artikel zeigt, wie das mit next/font funktioniert und worauf es dabei ankommt.
Code & Architektur
Statisches Rendering (SSG) vs. WordPress-Datenbank
Eine WordPress-Seite baut jede Seite bei jedem Aufruf neu zusammen — aus einer Datenbank, über PHP, im Moment des Besuchs. Eine statisch gerenderte Seite (SSG) ist dagegen schon fertig: vorgebaut zu HTML, ausgeliefert ohne Datenbank, ohne serverseitige Programm-Logik im Anfrage-Pfad. Dieser Unterschied klingt technisch, hat aber zwei sehr konkrete Folgen für eine Kanzlei: deutlich weniger Angriffsfläche und spürbar mehr Tempo. Dieser Artikel erklärt das Prinzip — und sagt ehrlich, wo dynamisches Rendering trotzdem seinen Platz hat.
Code & Architektur
Glossar: Web-Tech und Web-Recht für Kanzleien
Auf den anderen Insights tauchen Fachbegriffe wie DSGVO, CSP, LCP oder RAG auf — das hier ist die zentrale Übersicht für jeden, der die Begriffe nicht täglich nutzt. Tooltip auf dem Desktop, Tap auf dem Smartphone, ein Sprung hierher.
Wenn Sie das in Ruhe besprechen möchten
Lassen Sie uns 30 Minuten zur Außen-Sicht Ihrer Kanzlei sprechen.
Erst gratis-Vorprüfung über das URL-Tool — dann entscheiden Sie, ob ein 890-€-Tiefen-Audit für Sie Sinn ergibt.