[GUIDE] How to use Webflow in the GDPR Space | Wie du Webflow im Rahmen der DSGVO nutzen kannst

[Dennis_K (Dennis Karg)]

[GERMAN] → English below!

Update November 2024: Dieser Guide wurde im Hinblick auf das neue, derzeit gültige EU-U.S. Data Privacy Framework (DPF) vollständig neu verfasst und umfangreich aktualisiert.

Hinweis: Dieser Guide stellt keine juristische Beratung dar, sondern basiert auf praktischen Erfahrungen aus zahlreichen Kundenprojekten, die auch datenschutzrechtlich geprüft wurden. Meine Meinung, Empfehlungen und Einschätzungen sind nicht rechtsverbindlich.

Empfehlung: Wenn du dich zum ersten Mal mit den datenschutzrechtlichen Anforderungen an den Betrieb und die Erstellung von Websites – insbesondere von Webflow-Websites – auseinandersetzt, nimm dir ausreichend Zeit. Das Thema ist komplex, vielschichtig und unterliegt ständigen Änderungen. Es ist daher vollkommen in Ordnung, wenn du heute, morgen oder in den kommenden Wochen noch nicht alles verstehst. Wichtig ist jedoch, dass du dich mit den Grundlagen vertraut machst und in der Lage bist, Auskunft zu geben, sobald du professionell beginnst, (Webflow-)Websites für Kunden zu entwickeln.

Dieser Guide bezieht sich auf die Anforderungen des Bundesdatenschutzgesetzes (BSG), die Datenschutz-Grundverordnung (DSGVO), die seit ihrem Inkrafttreten am 25. Mai 2018 die rechtmäßige Verarbeitung personenbezogener Daten regelt, sowie auf das Telekommunikation-Digitale-Dienste-Datenschutzgesetz (TDDDG), das den Nutzerschutz und die Datenverarbeitung in digitalen Diensten konkretisiert.

Zunächst die Definition relevanter Begrifflichkeiten:

• Kunde: Eine natürliche oder juristische Person, die dich (als Agentur oder Freelancer) mit der Entwicklung und/oder dem Betrieb einer Website beauftragt.
• Nutzer/User: Geschlechtsneutrale Bezeichnung für eine oder mehrere natürliche Personen oder Personengruppen, die eine Website aufrufen und mit ihr interagieren.
• Nutzerdaten/Userdaten: Personenbezogene Daten, die auf eine identifizierte oder identifizierbare natürliche Person zurückzuführen sind.
• DSGVO: Abkürzung für Datenschutz-Grundverordnung, die deutsche Übersetzung der General Data Protection Regulation (GDPR).

Ausgangslage: Dieser Guide geht davon aus, dass du Websites mit Webflow für Kunden entwickelst, die ihren Sitz im Geltungsbereich des BDSG haben und ihre Webflow-Website auch über Webflow hosten. Solltest du eine Webflow-Website für dich selbst oder dein Unternehmen erstellen, gelten dieselben Maßnahmen für dich bzw. dein Unternehmen.

1. Vorwort: Warum dieser Guide?

Datenschutz und die damit verbundenen rechtlichen Anforderungen an die Entwicklung und den Betrieb digitaler Angebote wie Websites sind oft überwältigend, komplex und schwer verständlich. Dennoch gehört Datenschutz zu den zentralen Aspekten bei der Entwicklung und dem Betrieb von Websites. Dieser Guide soll dir den Einstieg in dieses anspruchsvolle Thema erleichtern und dir nützliche Hinweise und Tipps aus meiner langjährigen Erfahrung als Webentwickler an die Hand geben. Lass uns also loslegen:

Der rechtmäßige Betrieb einer Website durch ein Unternehmen mit Sitz innerhalb der Europäischen Union unterliegt den gesetzlichen Bestimmungen der General Data Protection Regulation (GDPR). Das deutsche Bundesdatenschutzgesetz (BDSG) überträgt die Anforderungen der DSGVO in nationales Recht, so wie es beispielsweise in der Schweiz durch das Datenschutzgesetz (DSG) oder in Österreich ebenfalls durch das Datenschutzgesetz (DSG) geschieht.

Alle diese Gesetze haben das Ziel, personenbezogene Daten von Nutzern zu schützen, die etwa durch Websites verarbeitet werden.

Außerhalb des Europäischen Wirtschaftsraums (EWR) – und damit außerhalb des Geltungsbereichs der DSGVO – gelten die jeweiligen Datenschutzgesetze der einzelnen Staaten. Diese können sich erheblich von der DSGVO unterscheiden. Für die DSGVO werden Datenschutzbestimmungen von Drittstaaten häufig als unzureichend oder nicht angemessen bewertet.

2. Was sind personenbezogene Daten gemäß der DSGVO?

Personenbezogene Daten umfassen alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen.

Darunter zählen gemäß der DSGVO:

• Identifikationsinformationen: Name, Adresse, Personalausweisnummern
• Kontaktinformationen: E-Mail-Adresse, Telefonnummer.
• Internetdaten: IP-Adressen, Cookies, Standortdaten.
• Gesundheitsdaten: Informationen über die physische oder mentale Gesundheit.
• Biometrische Daten: Fingerabdrücke, Gesichtserkennungsdaten.
• Rassische oder ethnische Herkunft.
• Politische Meinungen oder Mitgliedschaft in Gewerkschaften.
• Genetische Daten: Informationen aus einem DNA-Test.

Sobald mindestens eine dieser Informationen bei der Verwendung der Website durch dich, deinem Kunden oder einem Auftragsverarbeiter verarbeitet werden, greifen die Anforderungen der DSGVO bzw. des Bundesdatenschutzgesetzes (BDSG).

Wichtig: Gemäß Artikel 9 Absatz 1 DSGVO ist “die Verarbeitung personenbezogener Daten, aus denen die rassische und ethnische Herkunft, politische Meinungen, religiöse oder weltanschauliche Überzeugungen oder die Gewerkschaftszugehörigkeit hervorgehen, sowie die Verarbeitung von genetischen Daten, biometrischen Daten zur eindeutigen Identifizierung einer natürlichen Person, Gesundheitsdaten oder Daten zum Sexualleben oder der sexuellen Orientierung einer natürlichen Person untersagt”.

Solltest du für deinen Kunden eine Website entwickeln, die darauf abzielt, solche besonderen Kategorien personenbezogener Daten zu erheben, stelle sicher, dass du die entsprechenden Anforderungen gemäß Artikel 9 Absatz 2 DSGVO erfüllst.

3. Was ist ein Auftragsverarbeiter bzw. die Auftragsverarbeitung?

Ein Auftragsverarbeiter ist eine natürliche oder juristische Person, die im Rahmen einer zu erbringenden Leistung personenbezogene Daten von Nutzern im Auftrag des Kunden verarbeitet.

Am Beispiel von Webflow:
Wenn dein Kunde für den Betrieb seiner Webflow Website das von Webflow bereitgestellte Hosting verwendet, wird Webflow damit beauftragt, die entsprechenden Daten der Website an den Nutzer zu senden, wenn dieser die Domain/URL der Website aufruft. Um die Daten korrekt auszuliefern, wird dabei die IP-Adresse des Nutzers verarbeitet.

Damit Webflow, Inc. oder eine andere natürliche oder juristische Person als Auftragsverarbeiter für deinen Kunden im Sinne der DSGVO tätig werden darf, ist eine Vereinbarung zur Auftragsverarbeitung (AVV) erforderlich. Dies gilt für alle, die entweder:

• personenbezogene Daten im Auftrag verarbeiten, oder
• technischen Zugriff auf diese Daten haben.

Das bedeutet, dass auch du, wenn du Zugriff auf personenbezogene Daten der Nutzer deines Kunden hast oder diese verarbeitest, eine Vereinbarung zur Auftragsverarbeitung (AVV) mit deinem Kunden benötigst.

4. Die Vereinbarung zur Auftragsverarbeitung (AVV)

Damit personenbezogene Daten von dir, deinem Kunden oder einem Auftragsverarbeiter rechtmäßig verarbeitet werden dürfen, ist – wie bereits erwähnt – eine rechtsgültige Vereinbarung erforderlich. Diese sogenannte Vereinbarung zur Auftragsverarbeitung (AVV) regelt üblicherweise die Rechte, Pflichten, technisch-organisatorischen Maßnahmen (TOMs), den Umfang, die Dauer sowie die Art und Zwecke der Verarbeitung.

Anbieter von SaaS (Software as a Service) und PaaS (Platform as a Service) Lösungen verankern diese Vereinbarung häufig in Standardvertragsklauseln (engl. Standard Contractual Clauses). Diese werden von dir oder deinem Kunden im Rahmen eines Vertragsabschlusses, etwa bei der Kontoerstellung oder Buchung eines Dienstes, verbindlich akzeptiert. Es gibt jedoch auch Anbieter, die eine AVV zusätzlich oder ausschließlich als separates Dokument anbieten. Ein Beispiel hierfür ist Webflow, Inc., das seine AVV unter dem Titel “Data Processing Addendum” bereitstellt.

Bevor personenbezogene Daten im Auftrag verarbeitet werden, sollte sichergestellt sein, dass mit jedem Anbieter, der personenbezogene Daten verarbeitet, eine entsprechende Vereinbarung abgeschlossen wurde.

Nachfolgend 3 Szenarien, die dir näher bringen sollen, wie die datenschutzrechtliche Verantwortung jeweils zu bewerten ist:

Szenario 1:
Du wirst von deinem Kunden beauftragt, eine Website als Webflow-Projekt zu entwickeln. Die Website wird im eigenen Webflow-Workspace des Kunden gehostet, und externe Dienste werden vom Kunden direkt bezogen.

• In diesem Fall wirst du durch die Entwicklung der Website nicht automatisch zum Auftragsverarbeiter der Nutzerdaten. Das ändert sich jedoch, sobald du in irgendeiner Form Zugriff auf Nutzerdaten erhältst oder erhalten könntest.
• Da der Kunde die Website in seinem eigenen Workspace betreibt, beauftragt er Webflow, Inc. mit dem Hosting der Website. Webflow wird damit zum Auftragsverarbeiter des Kunden (nicht von dir), und der Kunde muss eine AVV mit Webflow abschließen.
• Wenn dein Kunde externe Dienste bezieht, die du in seinem Auftrag in die Website einbindest, erfassen diese Dienste im Auftrag deines Kunden Nutzerdaten. Daher muss dein Kunde mit jedem dieser Dienste eine (AVV) abschließen.
• Sobald du deinem Kunden bei der Einrichtung / Konfiguration etwaiger Dienste unterstützt und dadurch Zugriff auf Userdaten erhalten könntest, wirst du zum Auftragsverarbeiter für deinen Kunden und der Abschluss einer AVV zwischen dir und deinem Kunden ist notwendig.

Szenario 2:
Du wirst von deinem Kunden beauftragt, eine Website als Webflow-Projekt zu entwickeln. Die Website wird im eigenen Webflow-Workspace des Kunden gehostet, aber externe Dienste werden von dir bezogen, verwaltet und dem Kunden in Rechnung gestellt.

• In diesem Szenario wirst du mit hoher Wahrscheinlichkeit zum Auftragsverarbeiter, da du externe Dienste im Auftrag des Kunden verwaltest und diese Dienste Nutzerdaten in deinem Auftrag verarbeiten.
• Du benötigst eine AVV mit deinem Kunden sowie mit jedem von dir verwalteten externen Dienst. In der AVV mit deinem Kunden muss außerdem klar aufgeführt sein, welche Dienste (in dem Fall werden sie Subprozessoren engl. Subprocessors genannt) eingesetzt und genutzt werden und welche Daten wie verarbeitet werden.
• Die rechtliche Beziehung zwischen deinem Kunden und Webflow bleibt unverändert: Webflow bleibt der Auftragsverarbeiter des Kunden, und eine AVV zwischen dem Kunden und Webflow ist weiterhin notwendig.

Szenario 3:
Du wirst von deinem Kunden beauftragt, eine Website als Webflow-Projekt zu entwickeln, zu pflegen und zu betreiben. Die Website wird von dir gehostet, und alle externen Dienste werden von dir bezogen und verwaltet.

• In diesem Fall wirst du zum vollständigen Auftragsverarbeiter des Kunden für den Betrieb der Website. Dein Kunde schließt ausschließlich mit dir eine AVV für den Betrieb der Website ab.
• Webflow verarbeitet in deinem Auftrag Nutzerdaten zur Bereitstellung der Website. Du benötigst daher eine AVV mit Webflow.
• Externe Dienste, die von dir verwaltet werden, verarbeiten ebenfalls in deinem Auftrag Nutzerdaten. Mit jedem dieser Dienste ist eine separate AVV durch dich abzuschließen.
• Sofern du externe Partner / Unternehmen zur Erfüllung der vertraglich vereinbarten Leistungen für deinen Kunden beauftragst, welche dadurch ebenso Zugriff auf Userdaten der Website deines Kunden erhalten oder erhalten könnten, benötigst du auch mit diesen Partnern / Unternehmen eine AVV.

Persönliche Empfehlung: Unabhängig vom Szenario haftest du für alle von dir durchgeführten oder im Auftrag durchgeführten Verarbeitungstätigkeiten. Sei dir dessen bewusst! Es lohnt sich nicht, Wege zu suchen, um nicht als Auftragsverarbeiter zu gelten. Gehe stattdessen davon aus, dass du potenziellen Zugriff auf personenbezogene Daten hast, und betrachte den Abschluss einer AVV mit deinem Kunden als obligatorisch.

Sollte es bei dir oder deinem Kunden zu einem Daten-Leak kommen, bei dem unbefugte Dritte Zugriff auf personenbezogene Daten erhalten, fordern die Aufsichtsbehörden zunächst Nachweise über die Verarbeitungstätigkeiten – darunter auch die AVVs.

Stelle daher sicher, dass deine Verarbeitungstätigkeiten rechtmäßig sind, stets rechtskonform dokumentiert werden und die notwendigen Vereinbarungen mit Auftragsverarbeitern abgeschlossen sind.

Denke jedoch immer daran: Die Verantwortung für die Art und Weise, wie und welche Daten verarbeitet werden, liegt letztlich beim Auftraggeber der Verarbeitungstätigkeiten.

Wichtig: Die Verarbeitung personenbezogener Daten außerhalb des Europäischen Wirtschaftsraums (EWR) wird datenschutzrechtlich oft als nicht angemessen bewertet. Hier kommt das neue EU-U.S. Data Privacy Framework ins Spiel, das am 10. Juli 2023 in Kraft getreten ist.

5. Was ist das EU-U.S. Data Privacy Framework (DPF)?

Damit eine natürliche oder juristische Person mit Sitz in der EU überhaupt eine Vereinbarung zur Auftragsverarbeitung mit einem Unternehmen in einem Drittstaat wie den USA – etwa Webflow, Inc. – abschließen darf, muss die Europäische Kommission die datenschutzrechtlichen Maßnahmen des entsprechenden Drittstaates als „angemessen“ im Sinne der DSGVO bewerten.

Im Falle der USA liegt dieser Angemessenheitsbeschluss in Form des Data Privacy Frameworks (DPF) seit 10. Juli 2023 vor. Dieser Angemessenheitsbeschluss dient als Rechtsgrundlage für die Übermittlung personenbezogener Daten an zertifizierte Unternehmen mit Sitz in den USA, ohne dass zusätzliche Übermittlungsinstrumente oder Maßnahmen erforderlich sind.

Das entscheidende Stichwort hierbei ist „zertifizierte Unternehmen“: Trotz des Angemessenheitsbeschlusses dürfen personenbezogene Daten nur an Unternehmen mit Sitz in den USA übermittelt werden, die nach dem EU-U.S. Data Privacy Framework zertifiziert sind. Über die Liste des U.S. Department of Commerce kannst du überprüfen, ob das Unternehmen, mit dem du eine Vereinbarung zur Auftragsverarbeitung abschließen möchtest, entsprechend zertifiziert ist.

Ein Blick auf diese Liste zeigt beispielsweise, dass Webflow, Inc. gemäß dem DPF zertifiziert ist:

Tipp: Wenn du oder dein Kunde einen digitalen Dienst aus den USA für eine Website oder interne Zwecke nutzen möchten, kann diese Liste ebenfalls dabei helfen, festzustellen, ob der Dienst überhaupt rechtskonform eingesetzt werden darf.

6. Welche Nutzerdaten werden durch Webflow verarbeitet?

Je nach Verwendung von Webflow’s Features muss bei der Erhebung und Verarbeitung von Nutzerdaten differenziert werden:

(1) Das Webflow Projekt wird mit dem Export Feature in Form von statischem HTML, CSS & JavaScript extern gehostet:

• Durch Webflow werden keine personenbezogenen Daten verarbeitet

(2) Das Webflow Projekt wird mit der managed Hosting-Lösung von Webflow veröffentlicht und betrieben:

• IP-Adresse

(3) Die über Webflow gehostete Website nutzt das Webflow Form Feature zum Versenden von Nutzerdaten aus den jeweiligen Kontaktformularen per E-Mail:

• IP-Adresse
• Weitere Daten: Daten, die im Kontaktformular abgefragt werden, z. B. Name, E-Mail-Adresse oder individuelle Angaben (je nach Konfiguration des Formulars).

(4) Die über Webflow gehostete Website nutzt das Webflow Memberships Feature:

• IP-Adresse
• Name
• E-Mail Adresse
• Weitere Daten: Informationen, die im Mitgliederprofil angegeben werden, z. B. Adresse oder andere personenbezogene Angaben.

(5) Die über Webflow gehostete Website nutzt das Webflow eCommerce Feature:

• IP-Adresse
• Name
• Adresse
• Ggf. Telefonnummer
• E-Mail Adresse
• Zahlungsinformationen: Angaben zur Zahlungsabwicklung (z. B. Kreditkartendetails).
• Weitere Daten: Informationen, die im Checkout-Prozess abgefragt werden.

(6) Die über Webflow gehostete Website nutzt das Webflow Analyze Feature:

• IP-Adresse
• Weitere Daten: Noch zu definierende Informationen (TBD)

Vorsicht: Da dieses Feature erst kürzlich eingeführt wurde, liegen bislang nur wenige Details zu Funktionsweise, technischer Implementierung und konkret erfassten Daten vor.

(7) Die über Webflow gehostete Website nutzt das Webflow Optimize Feature:

• IP-Adresse
• Weitere Daten: Noch zu definierende Informationen (TBD)

Vorsicht: Da dieses Feature erst kürzlich eingeführt wurde, liegen bislang nur wenige Details zu Funktionsweise, technischer Implementierung und konkret erfassten Daten vor.

Je nach genutzten Features und spezifischen Gegebenheiten der Website müssen die Nutzer in der Datenschutzerklärung über die jeweiligen Verarbeitungstätigkeiten und deren Rechtsgrundlagen informiert werden. Dies ist eine grundlegende Voraussetzung, um die Website datenschutzkonform zu betreiben.

7. Quellen aller für die Website notwendigen Daten

Sollte eine rechtliche Prüfung der Webflow-Website ergeben, dass Daten an „nicht legitimierte“ Domains gesendet oder von diesen geladen werden, handelt es sich hierbei sehr wahrscheinlich um die folgenden Domains:

• cdn.prod.website-files.com
• {site-id}.cloudfront.net

Da diese Domains von der DSGVO als eigenständig und unabhängig angesehen werden, ist es erforderlich, in der Datenschutzerklärung zu erwähnen, wer diese Domains verwaltet und welche Daten sie verarbeiten. Hier eine Erklärung, was es mit diesen Domains auf sich hat:

cdn.prod.website-files.com und prod.website-files.com (früher: assets-global.website-files.com und assets.website-files.com) (verwaltet durch Webflow)

• Diese Domains werden genutzt, um CSS- und JavaScript-Dateien, die während der Entwicklung einer Webflow-Website generiert werden, sowie im Asset Panel oder CMS hochgeladene Dateien (z. B. Bilder, Videos, Lottie- und Rive-Dateien) bereitzustellen.
• Die Dateien werden auf einem Amazon S3 (Simple Storage Service) Server gespeichert, der Teil eines globalen Amazon CloudFront Clusters ist. Der Dienst wird durch Webflow verwaltet und über Cloudflare geroutet.

{site-id}.cloudfront.net (verwaltet durch Webflow)

• Diese Sub-Domain wird verwendet, um eine von Webflow bereitgestellte „lokale“ Kopie der JavaScript Bilbiothek jQuery mit der Version 3.5.1 zu laden, die für die technische Funktionalität verschiedener Funktionen von Webflow’s angebotenen Features notwendig ist.
• Auch diese Dateien werden auf einem Amazon S3 Server gehostet, der Teil eines globalen Amazon CloudFront Clusters ist und von Webflow verwaltet wird.

Amazon S3 und das CloudFront Content Delivery Network (CDN) sind Teil der Dienstleistungen von Amazon Web Services (AWS). AWS ist ein Auftragsverarbeiter von Webflow, der diese Dienste für Webflow bereitstellt. Details hierzu finden sich in Webflow’s Liste zu eingesetzten Auftragsverarbeiter, welche Teil des Data Privacy Addendums (Webflows Vereinbarung zur Auftragsverarbeitung) ist.

Bei diesen Diensten wird die IP-Adresse der Nutzer verarbeitet, um die angeforderten Dateien auszuliefern.

7.1 Kritische Datenschutzpunkte bei Drittanbieter-Skripten

Datenschutzrechtlich problematisch wird es, wenn Drittanbieter-Dienste wie Finsweet Attribute Lösungen, GSAP oder andere frei verfügbare JavaScript-Bibliotheken über Content Delivery Networks (CDNs) eingebunden werden, ohne eine Vereinbarung zur Auftragsverarbeitung abzuschließen.

Beispiele:

<script async src="https://cdn.jsdelivr.net/npm/@finsweet/attributes-cmsfilter@1/cmsfilter.js"></script>

oder

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script> 

Weder du als Entwickler noch dein Kunde haben Kontrolle über:

• die bereitgestellten Dateien,
• die übermittelten Nutzerdaten, oder
• die Drittanbieter-Dienste selbst (z. B. jsDelivr), die diese Daten bereitstellen.

Lade die benötigten Dateien herunter und hoste sie auf einem eigenen Webspace des Kunden. Verlinke die Dateien anschließend direkt von dort. Dadurch wird die Verarbeitung von Nutzerdaten durch externe Drittanbieter-Dienste vermieden.

Eine bloße Erwähnung der genutzten Anbieter in der Datenschutzerklärung reicht nicht aus. Es muss klar dokumentiert sein:

• welche Daten verarbeitet werden,
• durch wen, und
• auf welcher rechtlichen Grundlage dies geschieht.

Ohne diese Maßnahmen kann der Einsatz solcher Drittanbieter-Lösungen als Verstoß gegen die DSGVO gewertet werden.

8. Cookies, Local Storage und Session Storage

8.1 Standard-Cookies bei Webflow-Websites

Wenn eine Webflow Website über eine kundeneigene Domain (nicht über beispiel.webflow.io) betrieben wird und weder das Memberships- noch das eCommerce-Feature nutzt, wird standardmäßig der folgende Third-Party-Cookie gesetzt:

__cf_bm

• Quelle: Die von Webflow verwaltete Domain .prod.website-files.com, die zur Bereitstellung von Website-Assets wie Bildern, Videos, JavaScript-Dateien und CSS-Dateien verwendet wird.
• Zweck: Dieser Cookie wird von Cloudflare’s Bot Protection Service im Auftrag von Webflow gesetzt, um automatisierte Zugriffsanfragen auf die Dateien zu verhindern.
• Inhalt: Laut Cloudflare’s Dokumentation enthält dieser Cookie verschlüsselte Session-Informationen sowie einen Zeitstempel. Die Daten können nur von Cloudflare entschlüsselt werden und werden nicht zur Verfolgung oder Identifizierung von Nutzern verwendet.
• Einstufung: Technisch notwendig.

Wichtig: Cloudflare ist seit Mitte 2024 ein Auftragsverarbeiter von Webflow und stellt Dienste wie DNS-Routing, Bot Protection, Caching, Security, Traffic Mitigation und Fraud Detection bereit. Jedoch ist Cloudflare derzeit (Stand 18.11.2024) nicht in der offiziellen Liste der von Webflow eingesetzten Auftragsverarbeiter aufgeführt. Ich habe diesen Missstand am 16.11.2024 bei Webflow platziert und hoffe hier auf eine rasche Aktualisierung dieser Liste und ggf. zugehörigen Dokumenten.

8.2 Zusätzliche Cookies bei Verwendung von Memberships- oder eCommerce-Features

Werden die Memberships- oder eCommerce-Features von Webflow genutzt, können folgende Cookies gesetzt werden:

wf-csrf.sig / wf-csrf

• Zweck: Session-Cookies, die Besucher und Website durch Schutz vor Cross-Site Request Forgery (CSRF) Angriffe absichern.
• Einstufung: Technisch für die Sicherheit der Website und Nutzer notwendig.

__stripe_mid / __stripe_sid

• Quelle: Von Stripe zur Betrugsprävention bei Transaktionen gesetzt.
• Zweck: Zur Betrugsprävention durch Stripe eingesetzt und hilft Stripe, das Risiko einer versuchten Transaktion einzuschätzen.
• Einstufung: Technisch notwendig.

_dd_s

• Zweck: Noch unbekannt (TBD).

Standardmäßig setzt Webflow keine weiteren Cookies, sofern keine optionalen externen Dienste oder Webflow-Features eingebunden werden.

8.3 Webflow-Editor-spezifische Cookies und Local Storage Einträge

Wenn du oder dein Kunde die Website über den Webflow-Editor bearbeiten, können folgende Cookies und Local-Storage-Einträge erscheinen:

Cookies:

• wf_editor_{project-name}_{project-domain}
• wf_editor_{project-name}_{project-domain}.sig
• wf_exp_uniqueId
• wf_logout
• wf_user
• wflogin
• …

Local Storage Einträge:

• STATSIG_LOCAL_STORAGE_LOGGING_REQUEST
• STATSIG_LOCAL_STORAGE_STABLE_ID
• ably-transport-preference
• WebflowEditor
• webflowPersistentUIState
• WebflowEditorSession:{random-id]
• …

Diese Cookies und Einträge sind für die Bearbeitungsfunktionen des Webflow-Editors notwendig und nicht sichtbar für echte Nutzer der Website.

8.4 Eigene JavaScript-Lösungen und Speichermechanismen

Wenn du selbst JavaScript schreibst oder externe JavaScript-Dateien einbindest, die Informationen im Browser des Users speichern (z. B. über Cookies, Local Storage oder Session Storage), beachte Folgendes:

• Einwilligungspflicht: Jegliche Speicherung, insbesondere von Nutzerdaten, erfordert die ausdrückliche Zustimmung des Nutzers über die eingesetzte Consent Management Platform.
• Beispiele: Auch scheinbar harmlose Funktionen wie die Speicherung der Auswahl, ob ein User lieber den Dark- oder Light-Mode präferiert (sofern diese Funktion über JavaScript gelöst wird) bedürfen einer Zustimmung.

8.5 Hinweise zur Prüfung gespeicherter Daten

Um den technischen Status der Website aus Sicht echter Nutzer zu prüfen, öffne die Website im Inkognito-Modus deines Browsers und anschließend die Entwicklerkonsole (engl. Dev Tools). Unter „Applikation“ (engl. Application) findest du in den Tabs „Cookies“, „Local Storage“ und „Session Storage“ eine Übersicht aller gespeicherten Daten im Browser.

Unterschiede zwischen Local Storage und Session Storage

• Local Storage: Speichert Daten dauerhaft im Browser, bis der Nutzer diese manuell löscht (z. B. über die Browsereinstellungen).
• Session Storage: Speichert Daten nur während der aktuellen Browsersitzung. Daten werden gelöscht, sobald der Nutzer den Tab oder Browser schließt.

9. Zusammenfassung

Bevor ich abschließend einige nützliche Informationen und Antworten auf häufig gestellte Fragen gebe, fasse ich die wichtigsten Punkte zusammen:

Webflow, einschließlich der Formular-, Memberships- und eCommerce-Features, ist als Platform as a Service (PaaS) seit dem Inkrafttreten des EU-U.S. Data Privacy Frameworks (DPF) grundsätzlich datenschutzkonform einsetzbar – jedoch mit Einschränkungen.

Folgende 11 Aspekte solltest du zwingend beachten & prüfen:

9.1 Webflow Komponenten

Webflow’s native Elemente wie Youtube, Vimeo, Google Maps Embeds, Facebook Like Button oder X (Twitter) Button hingegen dürfen nur mit Zustimmung durch die User geladen und angezeigt werden. Es kann nicht verhindert werden, dass die IP der User beim Aufruf der Website nur mit Zustimmung an jene Anbieter gesendet wird, sollten diese Elemente nicht verwendet werden. Nachfolgend ein Bild zur Verdeutlichung, von welchen Elementen die Rede ist:

9.2 Fonts

Stelle sicher, dass Schriftarten (Fonts) immer lokal eingebunden sind. Seit dem Urteil des Landgericht München vom 20.01.2022 ist klar geregelt, dass der Abruf von Google Fonts über Google-Server einen Verstoß gegen das Recht auf informationelle Selbstbestimmung darstellt. Was nichts weiter bedeutet, als dass der Websitebetreiber aus Gründen der “Bequemlichkeit” die Fonts nicht lokal eingebunden, sondern die IP des Users an Google für die Bereitstellung der Dateien übermittelt, ohne dass der User darauf einen Einfluss hat. Beachte daher den löblicher Weise von Webflow gesetzten Hinweis in den Site-Settings im Bereich “Fonts”, dass die zu verwendenden Fonts manuell hochgeladen werden sollten (siehe nachfolgenden Screenshot).

Webflow selbst bietet innerhalb des Webflow Designers im Style Panel bei der Fontdefinierung einige Google Fonts als Vorauswahl an (siehe den rot markierten Bereich im nachfolgenden Screenshot). Wenn du eine dieser Fonts auswählst, bedeutet das, dass jene Fonts über das CDN von Google Fonts in die Website integriert werden, was nicht datenschutzkonform ist. Stelle sicher, dass du nur Fonts verwendest, im Bereich “Custom fonts” oder “Web fonts” zu finden sind (siehe den grün markierten Bereich im Screenshot).

Tipp: Solltest du Google Fonts einsetzen wollen, aber kein .woff2 Format von Google beim manuellen Download von Google Fonts erhalten, empfehle ich dir, die entsprechende Font bei google-fonts-helper kostenfrei herunterzuladen.

9.3 Formulare

Solltest du Webflow Forms verwenden und die Formulare mit einem Botschutz versehen wollen, vermeide unter allen Umständen die Verwendung von Webflow’s integrierter reCaptcha validation aka Google reCAPTCHA V2 (siehe nachfolgenden Screenshot).

Die von Google zur Verfügung gestellte Checkbox “Ich bin kein Roboter” (“I’m not a robot”) lädt zum einen Google Fonts über Google’s CDN nach und zum anderen muss der User zunächst eine Einwilligung über die Consent Management Plattform (CMP) für dessen Einsatz erteilen, was den Sinn, Zweck und die Funktionsweise von reCAPTCHA V2 obsolet macht. Aktiviere stattdessen beide Checkboxes in den Site-Settings im Bereich “Forms” im Abschnitt “Spam Protection”.

Wenn die Checkbox für “Bots are being blocked” aktiviert ist, ist nach erneuter Veröffentlichung der Website der von Cloudflare angebotene Bot Protection Service TURNSTILE aktiv.

Hinweis: Wenn du lediglich für die Entwicklung (nicht für den Betrieb) der Website verantwortlich bist, das Projekt das Webflow Forms Feature nutzt und die Website kurz vor der Veröffentlichung steht, blende in den Site-Settings im Bereich “Forms” im Abschnitt “Form submissions” alle Form Submissions für dich aus (siehe nachfolgenden Screenshot):

Wenn aktiviert, siehst du statt der Tabelle mit den Formulardaten weiter unten die Meldung “Form submission data is hidden because you told us you’re not the owner of the associated site.” (siehe nachfolgenden Screenshot):

Beachte: Das Ausblenden der Form Submissions befreit dich als Entwickler:in nicht von der Pflicht, mit deinem Kunden eine Vereinbarung über die Auftragsverarbeitung abzuschließen, da du dir trotzdem jederzeit wieder die Form Submissions anzeigen lassen kannst und damit Zugriff auf personenbezogene Daten der User erhältst.

9.4 Einbindung externer Dienste mit <script>- oder <iframe>-Tags

Wenn du externe Dienste wie Cal.com / Calendly, Typeform, iFrames von Jobportalen, Elfsight-Lösungen, Google Analytics, Google Ads oder ähnliche (die Liste wäre endlos) integrierst, gilt für nahezu 99 % dieser Dienste, dass sie aus datenschutzrechtlicher Sicht als optional betrachtet werden. Sie sollten immer so eingebunden werden, dass sie erst geladen und angezeigt werden, wenn der User über die Consent Management Platform (CMP) die entsprechende Zustimmung erteilt hat. Persönlich empfehle ich seit vielen Jahren, aufgrund der einfachen Einbindung und API, cookie-script.com (Affiliate Link).

Ausdrückliche Empfehlung meinerseits: Verlasse dich nicht auf die Funktion des „automatischen Blockierens von Drittanbieter-Software“, die viele CMP-Anbieter anbieten. Je nach Konfiguration und Art der Einbindung der Drittanbieter Elemente ist dies keine 100% zuverlässige Methode, um sicherzustellen, dass jene Elemente erst geladen und angezeigt werden, wenn der User dem Einsatz dieser zugestimmt hat. Lies die Dokumentation des CMP-Anbieters und passe die <script>- und <iframe>-Tags gemäß den Empfehlungen an. Dies gewährleistet, dass Drittanbieter-Dienste wirklich erst nach der Zustimmung der User aktiv werden.

Am Beispiel der Einbindung des Google Tag Managers mit der Dokumentation zum Blocken von Drittanbieter-Einbindungen von cookie-script.com (Affiliate Link):

Vorher:

<script type="text/javascript">
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-XXXXXXXX-X', 'auto');
ga('send', 'pageview');
</script>

Nachher:

<script type="text/plain" data-cookiescript="accepted" data-cookiecategory="targeting">
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-XXXXXXXX-X', 'auto');
ga('send', 'pageview');
</script>

9.5 Einbindung von Tools über Webflow’s Site Settings

Wenn du beauftragt wirst, Tools wie Google Analytics, Google Maps oder den Meta Pixel in eine Webflow-Website zu integrieren, führe dies unter keinen Umständen über den Bereich „SEO“ in den Site Settings des Webflow Projekts durch (siehe nachfolgenden Screenshot).

Bei einer Einbindung auf diese Art kann eine Consent Management Platform (CMP) eine vorherige Zustimmung vor deren Einsatz nicht gewährleisten, da diese Einbindungen immer vor der Abfrage der CMP geladen werden. Jene Skripte müssen also im Bereich “Custom Code” im Bereich manuell mit einem -Tag NACH der Einbindung der gewählten CMP eingebunden werden und gemäß der Dokumentation der CMP ggf. modifiziert werden.

Weitere Details siehe “9.4 Einbindung externer Dienste mit Script oder iFrame Tags”

9.6 Einbindung von frei verfügbaren Skripten über Cloud Delivery Networks (CDNs)

Vermeide die Einbindung von frei verfügbaren Skripte wie jene von Finsweet Attributes, GSAP etc. über die angebotenen CDNs (wie z. B. jsDelivr, unpkg, oder cdnjs).

Es existiert keine rechtliche Legitimierung zur Einbindung von Dateien über jene Anbieter, da weder du als Entwickler:in noch dein Kunde Kontrolle hat, welche Daten bereitgestellt werden und was mit den übermittelten Nutzerdaten geschieht. Wenn möglich, lade jene JavaScripte herunter, hoste sie auf einen eigenen verwalteten Webspace und binde sie von dort in die Website ein. Erinnerung: Dem Gesetzgeber ist es egal, ob Maßnahmen zum Datenschutz mehr Aufwand und Kosten bedeuten, es wird immer im Sinne der User und des Datenschutzes entschieden.

Weitere Details siehe Punkt “7.1 Kritische Datenschutzpunkte bei Drittanbieter-Skripten”

9.7 Vereinbarung über die Datenverarbeitung zwischen dem Websitebetreiber & Webflow

Wenn dein Kunde die Webflow-Website im kundeneigenen Webflow Workspace hostet, weise ihn darauf hin, das Webflow Data Processing Addendum (DPA) zu unterzeichnen.

Dieses Dokument erfüllt die Anforderungen der DSGVO für eine Vereinbarung zur Auftragsverarbeitung zwischen dem Kunden (als Verantwortlicher) und Webflow (als Auftragsverarbeiter).

Es ist unerlässlich, dass diese Vereinbarung vor der Verarbeitung personenbezogener Daten abgeschlossen wird.

9.8 Vereinbarung über die Auftragsverarbeitung zwischen dir als Entwickler:in und deines Kunden

Als Entwickler, der im Auftrag des Kunden eine (Webflow-)Website entwickelt, besteht eine hohe Wahrscheinlichkeit, dass du an irgendeiner Stelle Zugriff auf personenbezogene Daten der Website-Nutzer hast oder haben könntest. Dies gilt insbesondere dann, wenn du Tätigkeiten über die reine Entwicklung hinaus erbringst, die eine Verarbeitung von Nutzerdaten erfordern.

Beispiel 1: Die Website verwendet das native Webflow Formular Feature und Webflow zeigt in den Site-Settings die übermittelten Form Submissions an.

Beispiel 2: Du bindest Dateien von deiner eigenen Domain und eigenen Webspace in die Webflow Website des Kunden ein.

Beispiel 3: Die gehostete Webflow Website liegt in deinem Workspace und dein Kunde bezahlt dich dafür, die Website über Webflow zu hosten.

In diesen Fällen ist gemäß der DSGVO ausdrücklich erforderlich, dass du eine Verarbeitung zur Auftragsverarbeitung mit deinem Kunden abschließt.

Glücklicherweise stellt die deutsche Behörde für Datenschutz & Informationsfreiheit (BfDI) als Prüfstelle mittlerweile ein entsprechendes Muster für eine Vereinbarung über die Auftragsverarbeitung zum Download zur Verfügung.

Ich empfehle dir, eine von dir vorbereitete Vereinbarung an deinen Kunden mit der Bitte um Unterzeichnung zu senden, bevor du Zugriff auf Nutzerdaten erhältst und genau definiert ist, welche Leistungen du für deinen Kunden erbringen wirst.

9.9 Rechtliche Absicherung

Wenn du als Entwickler oder Agentur rechtlich relevante Dokumente (wie Impressum oder Datenschutzerklärung) für deine Kunden erstellst, achte darauf, deine Haftung für diese Dokumente ausdrücklich auszuschließen. Als Entwickler oder Agentur bist du nicht verpflichtet, rechtliche Beratung zu leisten. Die Verantwortung für die rechtliche Prüfung der Website und die Nutzung von Webflow als Platform as a Service (PaaS) und Hoster liegt beim Kunden.

Formulierungsvorschlag für Verträge oder Angebote:

“Der Auftraggeber hat die Nutzung von Webflow als PaaS (Platform as a Service) und Hoster der Website zur Verarbeitung von personenbezogenen Daten gemäß der Datenschutz-Grundverordnung rechtlich zu verantworten.
Sofern Gegenstand dieses Angebots die Erstellung von rechtlich relevanten Dokumenten wie dem Impressum und/oder der Datenschutzerklärung ist, sind jene Dokumente als Muster und nicht als Rechtsberatung zu werten.
Der Auftraggeber schließt mit der Bestätigung und Unterzeichnung dieses Angebots den Auftragnehmer von der Haftung gegenüber dieser Dokumente aus”

9.10 Webflow Apps

Webflow bietet innerhalb des eigenen Ökosystems eine Vielzahl von Apps von Drittanbietern an, mit welchen neben der Generierung von Elementen im Webflow Designer auch Services von Drittanbietern in die Website eingebunden werden und durch die tatsächlichen User der Website genutzt werden können. Bei letzterem wird durch die App meistens ein <script>-Tag in die Webflow Website eingefügt, ohne die Möglichkeit, diesen Tag für Consent Management Plattformen (CMP) zu modifizieren, um das Laden jener Skripte vor der Zustimmung der User blockieren. Da jene Services der Drittanbieter datenschutzrechtlich zu 99% als optional für die Website zu bewerten sind, ist es zwingend erforderlich, dass eine manuelle Einbindung (also nicht über die App) erfolgen muss.

Wenn du nicht weißt, wie eine App für die Einbindung von Drittanbieter Software die Webflow Website modifiziert, hilft nur das Analysieren des HTML Codes der Website vor und nach der Einbindung, um herauszufinden, ob und wie etwaige Tags (meist <script> und/oder <iframe>) eingebunden werden.

9.11 Webflow Analyze & Webflow Optimize

Wenn du erwägst Webflow Analyze und/oder Webflow Optimize zu verwenden, empfehle ich zuvor eine rechtliche Prüfung der Implementierung. Da zum aktuellen Stand zu wenig Erkenntnisse über die konkret erfassten und verarbeiteten Nutzerdaten vorliegen. kann ich erst in Zukunft nähere Einblicke dazu geben.

10. Häufig gestellte Fragen

10.1 Muss ich eine Consent Management Platform (CMP) ausschließlich in die Website einbinden, wenn die Website Drittanbieter-Cookies verwendet?

Nein. Eine CMP ist für weitaus mehr verantwortlich als nur für Cookies. Es ist der zentrale Mechanismus, um die User entscheiden zu lassen, welche Dienste / Funktionen eingesetzt und welche damit verbundene Verarbeitung ihrer personenbezogenen Daten vorgenommen werden. Ob ein CMP eingesetzt werden muss, ist nicht der Frage “personenbezogene Daten verarbeiten Ja / Nein” sondern ob “technisch erforderlich Ja / Nein” abhängig.

10.2 Woran erkenne ich, ob Cookies von Drittanbietern gesetzt werden?

Siehe nachfolgenden Screenshot am Beispiel der webflow.com Website geöffnet in Google Chrome / Microsoft Edge im Inkognito Modus: Öffne die Entwickler-Konsole (engl. Dev Tools) deines Browsers und gehe in den Tab “Applikation” (engl. Application). Dort im Abschnitt “Cookies” wählst du die Domain aus, unter der die Website betrieben wird. Anschließend siehst du in der rechten Tabellenansicht in jeder Zeile beginnend mit dem Namen des Cookies die Werte jedes Cookies. Zur Bewertung, ob ein Cookie von Drittanbietern stammt, ist die Spalte “Domain” wichtig. Ist dort eine andere Domain als webflow.com oder .webflow.com aufgeführt, ist dies ein Cookie von einem Drittanbieter (gelblich durch Google Chrome hervorgehoben).

10.3 Müssen Zustimmungen oder Ablehnungen der User über den Einsatz von Cookies dokumentiert/gespeichert werden?

Zitat von eRecht24 aus dem FAQ zum Webinar “Webinar Rechtssichere Website 2024” vom 17.01.2024 auf die Frage “Müssen bei dem Consent Tool die Einwilligungen / Wiederspruch gespeichert werden? Was wird hier empfohlen?”:

“In der Regel werden die Einwilligungen über die Consent-Tools gespeichert. An sich genügt es aber, wenn man nachweist, dass man einen funktionierenden Einwilligungsmechanismus auf der Webseite hat. Der Nachweis von Cookie-Einwilligungen ist bisher nicht Gegenstand von Rechtsstreitigkeiten.“

Folgt man also der Aussage von eRecht24, reicht ein Nachweis über ein technisch funktionierender Einwilligungsmechanismus und die Speicherung der User Consents ist nicht erforderlich. Gängige Consent Management Plattformen speichern die Consents ohnehin (anonymisiert) oder bieten dieses Feature als “Addon” an.

10.4 Muss ich mit meinem Kunden eine Vereinbarung zur Auftragsverarbeitung abschließen?

Siehe Punkt “9.8 Vereinbarung über die Auftragsverarbeitung zwischen dir als Entwickler:in und deines Kunden”

10.5 Muss ich eine Consent Management Platform (CMP) in die Webflow Website einbinden, auch wenn ich keine Drittanbieter Lösungen in die Website eingebunden habe?

Nein, nicht zwangsläufig. Da der von Cloudflare im Auftrag von Webflow gesetzte Cookie __cf_bm technisch erforderlich ist, reicht hier eine Information zu diesem Cookie in der Datenschutzerklärung aus. Wenn du jedoch User Präferenzen/Informationen in Form eines Cookies oder Einträgen im Session oder Local Storage mit JavaScript speicherst, benötigst du eine CMP, damit der User die Möglichkeit hat, dem zuzustimmen oder abzulehnen.

Weitere Details siehe Punkt “8.4 Eigene JavaScript-Lösungen und Speichermechanismen”

10.6 Ist eine Checkbox bei Kontaktformularen zur Bestätigung der Kenntnisnahme der Datenschutzerklärung Pflicht?

Nein. Sogar im Gegenteil, es gilt bei der DSGVO das Prinzip der Datenminimierung und die Zustimmung zur Datenverarbeitung gemäß der Datenschutzerklärung sollte nicht separat abgefragt werden.

10.7 Muss ich die Zustimmung des Users zum Laden von YouTube Videos einholen, auch wenn ich dieses mit dem “erweiterten Datenschutzmodus” einbinde?

Ja, da IP des Users ungefragt an YouTube übermittelt wird. Aus datenschutzrechtlicher Perspektive kann das Video auch ohne YouTube eingebunden werden, weshalb die Einbindung darüber als optional betrachtet wird.

10.8 Muss ich die Zustimmung des Users zum Laden von Vimeo Videos einholen, auch wenn ich das Vimeo Embed mit dem [dnt=”true”] (Do not track) Attribute einbinde?

Ja, da die IP des Users ungefragt an Vimeo übermittelt wird, auch mit dem “do not track” Attribut. Aus datenschutzrechtlicher Perspektive kann das Video auch ohne YouTube eingebunden werden, weshalb die Einbindung darüber als optional betrachtet wird.

10.9 Ich möchte frei verfügbare Lösungen wie Finsweet Attribute Lösungen, GSAP Produkte, Lenis, etc. in meine Website einbinden. Darf ich diese über die angebotenen <script>-Tags lösen, welche das notwendige JavaScript von einem Cloud Delivery Network (CDN) Anbieter wie jsDelivr oder Cloudfront laden?

Nein. In europäischen Datenschutzkreisen ist die Nutzung von CDNs im Allgemeinen sehr umstritten und die rechtliche Lage verhältnismäßig “schwammig”. Die Nutzung eines CDNs setzt jedoch ohnehin die allgemeinen rechtlichen Anforderungen gemäß hiesiger Datenschutzbestimmungen voraus, wie beispielsweise die Vereinbarung über die Auftragsverarbeitung.

Bindest du Dateien von Drittanbietern über eine Quelle in deine Website ein, mit denen kein Vertragsverhältnis besteht, hast du als Entwickler:in oder dein Kunde keine Möglichkeit der Kontrolle über die abgerufenen Dateien oder über die Verarbeitung der IP-Adresse der User, welche beim Abruf an den CDN Anbieter gesendet werden. Aus der Perspektive des Datenschutzes erfolgt damit eine absichtliche illegale Weitergabe von personenbezogenen Daten ohne Legitimierung.

Ich empfehle und rate dir daher eindringlich, dir die Dateien von dem CDN herunterzuladen und diese lokal auf einem (kunden)eigenen Webspace zu hosten und von dort in die Website einzubinden.

Erinnerung: Dem Gesetzgeber ist es egal, ob Maßnahmen zum Datenschutz mehr Aufwand und Kosten bedeuten, es wird immer im Sinne der User und des Datenschutzes entschieden. Das “berechtigte Interesse” gemäß Erwägungsgrund 47 DSGVO wird wie auch beim Einsatz von Google Fonts über Google’s Server an dieser Stelle haltlos sein, da jene Dateien auch heruntergeladen und lokal gehostet werden können.

Siehe auch wichtigen Hinweis in Punkt “7.1 Kritische Datenschutzpunkte bei Drittanbieter-Skripten”

10.10 Muss ich für das Einbinden des Google Tag Managers (GTM) zunächst die Zustimmung der User über die CMP einfordern?

Auf diese Frage lässt sich keine eindeutige Antwort geben, da die Nutzung des Google Tag Managers (GTM) ohne vorherige Zustimmung rechtlich umstritten ist. Letztlich musst du selbst abwägen, ob und in welchem Umfang du den GTM einsetzen möchtest. Klar ist jedoch, dass der GTM ein mächtiges Tool ist, das es auch Nutzern ohne große Coding-Kenntnisse ermöglicht, Drittanbieterdienste oder eigenes JavaScript nachzuladen. Der Tag Manager fungiert somit als eine Art Container, der externe Ressourcen steuert und unabhängig von der Website selbst konfiguriert wird.

Ein GTM, der ohne verknüpfte Dienste (sogenannte „Tags“) eingebunden wird, setzt keine Cookies. Dennoch verarbeitet er notwendigerweise die IP-Adresse des Nutzers, da diese beim Aufruf der Website benötigt wird, um zu wissen, wohin die eingebundenen Tags ausgespielt werden sollen. Aus diesem Grund ist der Abschluss einer Vereinbarung zur Auftragsverarbeitung zwischen dem Websitebetreiber und Google verpflichtend, auch wenn der GTM alleinstehend verwendet wird.

Fallbeispiel 1: Minimale Nutzung des GTM
Angenommen, du nutzt den GTM, um lediglich Google Analytics, den Meta Pixel oder den LinkedIn Pixel in die Website einzubinden. Datenschützer argumentieren hier oft mit dem Grundsatz der Datenminimierung gemäß Artikel 5 Absatz 1 Bst. c DSGVO. In diesem Fall wird der GTM als unnötige und unangemessene „Brücke“ in der Datenverarbeitung angesehen. Schließlich könnten diese Dienste auch direkt in die Website eingebunden werden, ohne dass die personenbezogenen Daten der Nutzer zusätzlich durch den GTM verarbeitet werden müssten.

Sollte ein Nutzer in diesem Zusammenhang eine Beschwerde bei einer Datenschutzaufsichtsbehörde einreichen und auf Grundlage des Grundsatzes der Datenminimierung klagen, gehen Datenschützer davon aus, dass die Behörde dem Nutzer Recht geben würde. Der Websitebetreiber müsste daraufhin die Einbindung der Dienste ohne den GTM vornehmen und unter Umständen Schadensersatz leisten.

Fallbeispiel 2: Erweiterte Nutzung des GTM
In diesem Szenario wird der GTM von Marketing-Agenturen oder -Teams des Websitebetreibers genutzt, um eine Vielzahl zusätzlicher Dienste einzubinden und zu steuern. Zudem könnte der GTM so konfiguriert werden, dass Partner des Websitebetreibers Änderungen am GTM-Container vornehmen können, ohne direkten Zugriff auf die kritische Infrastruktur der Website zu erhalten.

Unabhängig von dem Fall müssen optionalen Dienste, die über den GTM eingebunden werden, eine vorherige Zustimmung der Nutzer durch eine Consent Management Platform (CMP) einholen, bevor sie aktiviert werden können.

Der Unterschied zu Fallbeispiel 1 liegt jedoch in der Argumentationsgrundlage: Der Websitebetreiber könnte sich in diesem Fall auf das „berechtigte und legitime Interesse“ gemäß Artikel 6 Absatz 1 Bst. f DSGVO berufen. Datenschützer halten es für wahrscheinlich, dass die Argumentation vor Gericht Bestand hätte, weisen jedoch darauf hin, dass es hierfür keine rechtliche Gewissheit gibt.

Risikoabschätzung
Die Nutzung des Google Tag Managers – unabhängig davon, ob mit oder ohne Tags – birgt somit ein datenschutzrechtliches Risiko. Während der Einsatz des GTM in Fallbeispiel 1 höchstwahrscheinlich als nicht konform angesehen würde, bietet Fallbeispiel 2 eine stärkere rechtliche Grundlage für den Einsatz. Dennoch bleibt der Einsatz von GTM ohne vorherige Zustimmung der Nutzer umstritten, und die Entscheidung für oder gegen den GTM sollte stets sorgfältig abgewogen werden.

Zusammenfassung

• Der GTM setzt ohne verbundene Tags keine Cookies, verarbeitet jedoch die IP-Adresse der Nutzer und erfordert daher eine Vereinbarung zur Auftragsverarbeitung mit Google.
• Fallbeispiel 1: Die Nutzung des GTM für einfache Dienste wie Google Analytics oder Meta Pixel wird in der Regel als unnötig und nicht datenschutzkonform betrachtet, da diese Dienste auch ohne den GTM direkt eingebunden werden könnten.
• Fallbeispiel 2: Der erweiterte Einsatz des GTM kann durch berechtigte Interessen gerechtfertigt werden, birgt jedoch weiterhin rechtliche Unsicherheiten.
• Es ist stets sicherzustellen, dass optionale Dienste, die über den GTM eingebunden werden, erst nach Zustimmung des Nutzers durch eine CMP aktiviert werden.
• Der Einsatz des GTM ohne vorherige Zustimmung ist ein datenschutzrechtliches Risiko und sollte nur nach sorgfältiger Abwägung erfolgen.

10.11 Sollte ich die Consent Management Platform (CMP) mithilfe des Google Tag Managers (GTM) in die Website einbinden?

Ich rate dir davon ab. Auch wenn die großen CMP Anbieter teils sehr detaillierte Anleitungen dafür liefern, ist der GTM 1. als Marketinginstrument zu betrachten, weshalb er in vielen Fällen durch AdBlocker gar nicht erst geladen wird (kein GTM, kein Consent Management) und 2. ist der Einsatz des GTM ohne Zustimmung über eine CMP als rechtliches Risiko einzuschätzen (Siehe Antwort auf Frage ”10.10 Muss ich für das Einbinden des Google Tag Managers (GTM) zunächst die Zustimmung der User über die CMP einfordern?”).

10.12 Kann ich die Einbindung der JavaScript Bibliothek jQuery über Cloudfront’s CDN in ein Webflow Projekt unterbinden?

Ja, es ist möglich, die Einbindung von jQuery über Cloudfront’s CDN in ein Webflow-Projekt zu verhindern. Allerdings erfordert dies gegebenenfalls signifikante Anpassungen an der Netzwerk- und Sicherheitsinfrastruktur deines Kunden. Die Rede ist davon, Cloudflare als DNS Provider für die Domain der Website zu verwenden und über einen Cloudflare Worker ein sogenanntes “Hot-Replacement” durchzuführen.

Cloudflare als DNS-Provider einrichten
Um Cloudflare zu verwenden, ersetzt du die Nameserver des Domain-Anbieters deines Kunden durch die von Cloudflare bereitgestellten Nameserver. Cloudflare übernimmt anschließend das DNS-Routing für die Domain der Website. Stand heute entstehen dafür keine Kosten für deinen Kunden, da Cloudflare den Basisservice kostenfrei anbietet.

Sobald dieser wirklich sehr einfache Einrichtungsprozess von Cloudflare abgeschlossen ist, kannst du oder dein Kunde ein Cloudflare Worker anlegen und diesem folgenden Code hinzufügen:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  // Die URL, die ersetzt werden soll
  const targetUrl = 'https://{{SITE_ID}}.cloudfront.net/js/jquery-3.5.1.min';
  // Die URL, die stattdessen verwendet werden soll
  const newUrl = 'https://subdomain.kundendomain.com/jquery-3.5.1.min.js';

  // Erstelle eine neue Instanz des HTMLRewriter
  let rewriter = new HTMLRewriter()
    .on('script[src]', {
      element(element) {
        const src = element.getAttribute('src');
        // Überprüfe, ob das src-Attribut mit der Ziel-URL beginnt
        if (src.startsWith(targetUrl)) {
          // Ersetze das src-Attribut durch die neue URL
          element.setAttribute('src', newUrl);
        }
      }
    });

  // Hole die ursprüngliche Antwort
  const response = await fetch(request);

  // Wende den HTMLRewriter auf die Antwort an
  return rewriter.transform(response);
}

Bemerkungen zum Code:

1. targetUrl konfigurieren:
   Kopiere die URL aus dem src-Attribut des <script>-Tags, mit dem jQuery von Cloudfront eingebunden wird, und füge sie als Wert der Variable targetUrl ein.
2. jQuery lokal hosten:
   Lade die jQuery-Datei von der targetUrl herunter und speichere sie auf einem öffentlich zugänglichen Webspace deines Kunden.
   Alternativ kannst dein Kunde dafür ein Cloudflare R2 Bucket verwenden, der bis zu einer bestimmten Traffic-Obergrenze kostenfrei ist.
3. newUrl konfigurieren:
   Gib die URL der lokal gehosteten jQuery-Datei als Wert der Variable newUrl an.

Nachdem du diese Anpassungen vorgenommen hast, klicke auf „Deploy“, um den Worker zu speichern.

Cloudflare Worker aktivieren
Navigiere im Tab “Settings” des Workers zum Bereich “Domains & Routes”.

Füge die Domain des Kunden in folgender Schreibweise hinzu:

*kundendomain.com/*

Fertig.

Ablauf des Hot-Replacement-Prozesses
Nach der Aktivierung des Workers wird beim Aufruf der Website folgendes passieren:

1. Der Nutzer ruft die Website über die Kundendomain auf, woraufhin seine IP-Adresse an Cloudflare als DNS-Provider gesendet wird.
2. Cloudflare holt die HTML-Datei der Website von den Webflow-Servern ab.
3. Der Cloudflare Worker durchsucht den HTML-Code nach einem <script>-Tag, dessen src-Attribut mit der URL aus targetUrl übereinstimmt.
4. Wird ein entsprechender <script>-Tag gefunden, ersetzt der Worker die URL im src-Attribut durch die neue URL aus newUrl.
5. Cloudflare liefert die modifizierte HTML-Datei an den Nutzer aus.

Dieser gesamte Prozess findet auf Serverebene statt und ist daher für den Nutzer nicht spürbar. Die Geschwindigkeit des Vorgangs hängt nicht von der Internetverbindung des Nutzers ab, sondern von der Infrastruktur von Cloudflare.

Auch hier gilt, da Cloudflare mindestens die IP des Users im Auftrag des Websitebetreibers (also deines Kunden) verarbeitet, muss dein Kunde eine AVV mit Cloudflare abschließen.

10.13 Mein Kunde fragt mich, wie Element X von Anbieter Y in die Website eingebunden werden muss, damit sie DSGVO konform ist. Wie soll ich mit dieser Situation umgehen?

In dieser Situation ist Vorsicht geboten, denn als Entwickler darfst du, wenn du kein Anwalt bist, keine Rechtsberatung anbieten. Dennoch kannst du deinem Kunden Empfehlungen geben und deine Erfahrungen teilen – allerdings mit einem klaren Hinweis darauf, dass diese nicht rechtsverbindlich sind, da du kein juristischer Experte bist.

Empfehlung für den Umgang mit dieser Anfrage:

1. Hinweis auf eigene Grenzen:
   Weisen deinen Kunden darauf hin, dass du die datenschutzrechtlichen Aspekte nach bestem Wissen und Gewissen berücksichtigst, aber keine rechtlichen Garantien geben kannst.
2. Empfehlung zur Rechtsprüfung:
   Mache deutlich, dass die rechtliche Prüfung und alle relevanten Entscheidungen durch deinen Kunden erfolgen müssen. Dein Kunde sollte bei Unsicherheiten einen Fachanwalt hinzuziehen.
3. Frühzeitige Klarstellung:
   Idealerweise sollte bereits im Angebot oder Vertrag stehen, dass du keine Haftung für die rechtliche Bewertung der Datenschutzmaßnahmen übernimmst. Siehe hierzu auch den Punkt “9.9 Rechtliche Absicherung”.
4. Dokumentation deiner Empfehlungen:
   Notiere klar, welche Empfehlungen du gegeben hast und dass diese keine Rechtsberatung darstellen. So schützt du dich im Falle von Missverständnissen oder Streitigkeiten.

10.14 Mein Kunde möchte entgegen meiner fachlichen Empfehlung, dass ich Dinge umsetze, die datenschutzrechtlich nicht konform sind. Wie soll ich mit dieser Situation umgehen?

Diese Situation erfordert besondere Sorgfalt, da du als Entwickler für die Einhaltung rechtlicher Vorgaben in deinem Werk haftest. Verträge zur Entwicklung von Websites fallen in der Regel unter das Werkvertragsrecht. Das bedeutet, dass du verpflichtet bist, ein Produkt zu liefern, das frei von Sachmängeln ist und nicht gegen geltendes Recht verstößt.

Empfehlung für den Umgang mit dieser Situation:

1. Klarstellung der rechtlichen Risiken:
   Erläutere deinem Kunden, warum die gewünschte Umsetzung nicht datenschutzkonform ist und welche rechtlichen Konsequenzen dies haben könnte. Betone, dass die Verantwortung für diese Entscheidung vollständig beim Kunden liegt.
2. Schriftliche Bestätigung einholen:
   Wenn dein Kunde trotz deiner fachlichen Warnung auf der Umsetzung besteht, fordere eine schriftliche Bestätigung des Kunden ein. Diese sollte klar formulieren, dass der Kunde entgegen deiner professionellen Meinung auf der Umsetzung besteht und die volle Verantwortung für eventuelle rechtliche Folgen übernimmt.

Mögliche Konsequenzen abschätzen:
Überlege, ob die Zusammenarbeit in solchen Fällen weiterhin tragbar ist. Die Umsetzung nicht rechtskonformer Maßnahmen könnte langfristig auch deinen Ruf oder deine rechtliche Position gefährden.

10.15. Wo kann ich oder mein Kunde die Veinbarung über die Datenverarbeitung AVV herunterladen/unterzeichnen?

Auf der Webflow’s Seite des von Webflow genannten “Data Processing Addendum” befindet sich ein Link zum Download des Data Processing Addendum über DocuSign von Webflow.

→ GUIDE ENDE ←

Eine Bitte an dich und alle: Solltest du eine Frage, ein Problem oder einen Wunsch dem Guide betreffend haben, schreibe mir bitte keine private Nachricht, sondern verfasse einen Kommentar unter diesem Beitrag, damit auch andere von potenziellen Lösungsansätzen profitieren können.

Solltest du meine Arbeit für die Community unterstützen wollen, kannst du dies mit einer Mitgliedschaft über meinen Patreon-Account tun: patreon.com/denniskarg

Noch ein Hinweis in eigener Sache: Du bist ein deutschsprachiger Webflow Nutzer, dann heißt dich die Webflow DACH Community mit insgesamt über 1.600 Mitgliedern auf Discord und Facebook herzlich willkommen.

Ich hoffe, ich konnte dir damit helfen.

Dennis Karg (Patreon / X-Twitter / LinkedIn / Webflow)

[ENGLISH]

Show English language guide

Update November 2024: This guide has been completely rewritten and extensively updated to reflect the new, currently applicable EU-U.S. Data Privacy Framework (DPF).

Note: This guide does not constitute legal advice but is based on practical experience from numerous client projects that have also been reviewed for data protection compliance. My opinions, recommendations, and assessments are not legally binding.

Recommendation: If you are addressing data protection requirements for operating and creating websites—particularly Webflow websites—for the first time, take your time. The topic is complex, multifaceted, and subject to constant changes. It is entirely fine if you do not grasp everything today, tomorrow, or even in the coming weeks. However, it is crucial to familiarize yourself with the basics and be able to provide information once you start professionally developing (Webflow) websites for clients.

This guide refers to the requirements of the Federal Data Protection Act (BDSG), the General Data Protection Regulation (GDPR), which has regulated the lawful processing of personal data since its entry into force on May 25, 2018, as well as the Telecommunications Telemedia Data Protection Act (TTDSG), which specifies user protection and data processing in digital services.

Let us start with the definition of relevant terms:

• Client: A natural or legal person who commissions you (as an agency or freelancer) to develop and/or operate a website.
• User: A gender-neutral term for one or more natural persons or groups of persons who access and interact with a website.
• User data: Personal data that can be traced back to an identified or identifiable natural person.
• GDPR: An abbreviation for General Data Protection Regulation, the international name for the EU regulation.

Initial Scenario: This guide assumes that you are developing websites with Webflow for clients who are located within the scope of the BDSG and also host their Webflow websites via Webflow. If you are creating a Webflow website for yourself or your company, the same measures apply to you or your company.

1. Foreword: Why this guide?

Data protection and the associated legal requirements for developing and operating digital offerings like websites are often overwhelming, complex, and difficult to understand. However, data protection is a central aspect of website development and operation. This guide is designed to help you get started with this challenging topic and provide useful insights and tips based on my many years of experience as a web developer. Let’s dive in:

The lawful operation of a website by a company based within the European Union is governed by the General Data Protection Regulation (GDPR). The German Bundesdatenschutzgesetz (BDSG) transposes the GDPR’s requirements into national law, as does, for example, the Swiss Data Protection Act (DSG) or Austria’s Data Protection Act (DSG).

All these laws aim to protect personal data of users processed by websites.

Outside the European Economic Area (EEA)—and thus outside the scope of the GDPR—the respective data protection laws of individual countries apply. These can differ significantly from the GDPR. For the GDPR, data protection regulations of third countries are often considered inadequate or insufficient.

2. What is personal data under the GDPR?

Personal data includes all information relating to an identified or identifiable natural person.

According to the GDPR, this includes:

• Identification information: Name, address, identity card numbers.
• Contact information: Email address, phone number.
• Internet data: IP addresses, cookies, location data.
• Health data: Information about physical or mental health.
• Biometric data: Fingerprints, facial recognition data.
• Racial or ethnic origin.
• Political opinions or trade union membership.
• Genetic data: Information derived from DNA tests.

As soon as at least one of these types of information is processed when using the website by you, your client, or a processor, the requirements of the GDPR or the Federal Data Protection Act (BDSG) apply.

Important: According to Article 9(1) GDPR, “Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation shall be prohibited.”

If you are developing a website for your client that aims to collect such special categories of personal data, ensure that you meet the respective requirements outlined in Article 9(2) GDPR.

3. What is a Processor or Processing Agreement?

A processor is a natural or legal person who processes personal data of users on behalf of a client as part of a service provided.

Using Webflow as an example:

If your client uses Webflow’s hosting services for their website, Webflow is tasked with delivering the corresponding website data to the user when the domain/URL is accessed. To correctly deliver the data, the user’s IP address is processed.

For Webflow, Inc., or any other natural or legal person to act as a processor for your client under the GDPR, a Data Processing Agreement (DPA) is required. This applies to any entity that either:

• Processes personal data on behalf of a client, or
• Has technical access to such data.

This means that if you have access to your client’s users’ personal data or process it, you also need a DPA with your client.

4. The Data Processing Agreement (DPA)

For personal data to be processed lawfully by you, your client, or a processor, a valid agreement is required—as mentioned earlier. This so-called Data Processing Agreement (DPA) typically regulates the rights, obligations, technical and organizational measures (TOMs), the scope, duration, as well as the nature and purpose of the processing.

Providers of SaaS (Software as a Service) and PaaS (Platform as a Service) solutions often embed this agreement in standard contractual clauses. These are bindingly accepted by you or your client as part of a contract, for example, when creating an account or subscribing to a service. Some providers, however, offer a DPA additionally or exclusively as a separate document. An example is Webflow, Inc., which provides its DPA under the title “Data Processing Addendum.”

Before processing personal data on behalf of a client, it must be ensured that a corresponding agreement is concluded with every provider that processes personal data.

Below are three scenarios to illustrate how data protection responsibility should be evaluated in each case:

Scenario 1:
You are commissioned by your client to develop a website as a Webflow project. The website is hosted in the client’s Webflow workspace, and external services are directly contracted by the client.

• In this case, by developing the website, you do not automatically become a processor of the user data. However, this changes as soon as you gain access to or could potentially access user data in any way.
• Since the client operates the website in their own workspace, they commission Webflow, Inc. with hosting the website. Webflow then acts as the processor for the client (not for you), and the client must establish a DPA with Webflow.
• If the client contracts external services that you integrate into the website on their behalf, these services collect user data on behalf of the client. Therefore, the client must establish a DPA with each of these services.
• Once you assist the client in setting up/configuring such services and could gain access to user data, you become a processor for your client, and a DPA between you and your client is required.

Scenario 2:
You are commissioned by your client to develop a website as a Webflow project. The website is hosted in the client’s Webflow workspace, but external services are contracted, managed, and billed by you.

• In this scenario, you are likely to become a processor since you manage external services on behalf of the client, and these services process user data on your behalf.
• You will need a DPA with your client and with every external service you manage. The DPA with your client must also explicitly list the services (known as subprocessors) used and how data is processed.
• The legal relationship between your client and Webflow remains unchanged: Webflow continues to be the processor for the client, and a DPA between the client and Webflow remains necessary.

Scenario 3:
You are commissioned by your client to develop, maintain, and operate a website as a Webflow project. The website is hosted by you, and all external services are contracted and managed by you.

• In this case, you become the primary processor for the client regarding the operation of the website. Your client will only establish a DPA with you for the operation of the website.
• Webflow processes user data on your behalf to provide the website. You, therefore, need a DPA with Webflow.
• External services you manage also process user data on your behalf. You must establish a separate DPA with each of these services.
• If you engage external partners/companies to fulfill contractual obligations for your client, which grant them access to or the possibility of accessing user data from the client’s website, you must also establish a DPA with these partners/companies.

Personal Recommendation: Regardless of the scenario, you are liable for all processing activities conducted by you or on your behalf. Be aware of this! It is not worth seeking ways to avoid being considered a processor. Instead, assume you have potential access to personal data and treat the conclusion of a DPA with your client as mandatory.

If you or your client experience a data breach where unauthorized third parties gain access to personal data, supervisory authorities will first request evidence of processing activities, including DPAs.

Ensure that your processing activities are lawful, consistently documented in compliance with regulations, and that the necessary agreements with processors are in place.

Always keep in mind: The responsibility for how and which data is processed ultimately lies with the client commissioning the processing activities.

Important: The processing of personal data outside the European Economic Area (EEA) is often deemed inadequate in terms of data protection. This is where the new EU-U.S. Data Privacy Framework comes into play, which came into effect on July 10, 2023.

5. What is the EU-U.S. Data Privacy Framework (DPF)?

For a natural or legal person based in the EU to enter into a Data Processing Agreement with a company in a third country like the United States—such as Webflow, Inc.—the European Commission must assess the data protection measures of the third country as “adequate” under the GDPR.

In the case of the United States, this adequacy decision is provided through the Data Privacy Framework (DPF), effective since July 10, 2023. This adequacy decision serves as a legal basis for transferring personal data to certified companies based in the U.S. without requiring additional transfer instruments or measures.

The key term here is “certified companies”: Despite the adequacy decision, personal data may only be transferred to companies in the U.S. that are certified under the EU-U.S. Data Privacy Framework. You can check the list maintained by the U.S. Department of Commerce to verify whether the company you intend to enter into a Data Processing Agreement with is certified.

A glance at this list shows, for example, that Webflow, Inc. is certified under the DPF:

Tip: If you or your client wish to use a digital service from the U.S. for a website or internal purposes, this list can also help determine whether the service can be used in compliance with the law.

6. What user data is processed by Webflow?

Depending on the use of Webflow’s features, the collection and processing of user data must be distinguished as follows:

1. The Webflow project is exported and hosted externally as static HTML, CSS, and JavaScript:

   • No personal data is processed by Webflow.

2. The Webflow project is published and operated using Webflow’s managed hosting solution:

   • IP Address

3. The Webflow-hosted website uses the Webflow Form feature to send user data from contact forms via email:

   • IP Address
   • Additional data: Data requested in the contact form, such as name, email address, or custom information (depending on the form configuration).

4. The Webflow-hosted website uses the Webflow Memberships feature:

   • IP Address
   • Name
   • Email Address
   • Additional data: Information provided in the member profile, such as address or other personal details.

5. The Webflow-hosted website uses the Webflow eCommerce feature:

   • IP Address
   • Name
   • Address
   • Phone number (if applicable)
   • Email Address
   • Payment information: Details required for payment processing (e.g., credit card details).
   • Additional data: Information collected during the checkout process.

6. The Webflow-hosted website uses the Webflow Analyze feature:

   • IP Address
   • Additional data: To be defined (TBD)

   Caution: As this feature was recently introduced, there is limited information on its functionality, technical implementation, and the specific data collected.

7. The Webflow-hosted website uses the Webflow Optimize feature:

   • IP Address
   • Additional data: To be defined (TBD)

   Caution: As this feature was recently introduced, there is limited information on its functionality, technical implementation, and the specific data collected.

Depending on the features used and the specific circumstances of the website, users must be informed in the privacy policy about the respective processing activities and their legal basis. This is a fundamental requirement for operating the website in compliance with data protection regulations.

---

7. Sources of all data necessary for the website

If a legal review of the Webflow website reveals that data is being sent to or loaded from “unauthorized” domains, the likely domains involved are:

• cdn.prod.website-files.com
• {site-id}.cloudfront.net

Since these domains are considered independent under the GDPR, it is necessary to mention in the privacy policy who manages these domains and what data they process. Here’s an explanation:

cdn.prod.website-files.com and prod.website-files.com (formerly: assets-global.website-files.com and assets.website-files.com) (managed by Webflow)

• These domains are used to deliver CSS and JavaScript files generated during the development of a Webflow website, as well as files uploaded in the Asset Panel or CMS (e.g., images, videos, Lottie, and Rive files).
• The files are stored on an Amazon S3 (Simple Storage Service) server, which is part of a global Amazon CloudFront cluster. The service is managed by Webflow and routed through Cloudflare.

{site-id}.cloudfront.net (managed by Webflow)

• This subdomain is used to load a “local” copy of the JavaScript library jQuery (version 3.5.1), required for the technical functionality of various features offered by Webflow.
• These files are also hosted on an Amazon S3 server, which is part of a global Amazon CloudFront cluster managed by Webflow.

Amazon S3 and the CloudFront Content Delivery Network (CDN) are services provided by Amazon Web Services (AWS). AWS acts as a processor for Webflow and provides these services to Webflow. Details about this can be found in Webflow’s list of subprocessors, which is part of the Data Processing Addendum (Webflow’s Data Processing Agreement).

For these services, the user’s IP address is processed to deliver the requested files.

7.1 Critical Data Protection Issues with Third-Party Scripts

Data protection becomes problematic when third-party services such as Finsweet Attribute solutions, GSAP, or other freely available JavaScript libraries are integrated via Content Delivery Networks (CDNs) without a Data Processing Agreement (DPA) in place.

Examples:

<script async src="https://cdn.jsdelivr.net/npm/@finsweet/attributes-cmsfilter@1/cmsfilter.js"></script>

or

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>

Neither you as a developer nor your client has control over:

• the provided files,
• the transmitted user data, or
• the third-party services themselves (e.g., jsDelivr) that provide these files.

Download the necessary files and host them on the client’s own webspace. Then link the files directly from there. This prevents the processing of user data by external third-party services.

Merely mentioning the providers used in the privacy policy is not sufficient. It must be clearly documented:

• which data is processed,
• by whom, and
• on what legal basis.

Without these measures, the use of such third-party solutions may be considered a violation of the GDPR.

8. Cookies, Local Storage, and Session Storage

8.1 Standard Cookies on Webflow Websites

If a Webflow website is operated on a client-owned domain (not on example.webflow.io) and neither the Memberships nor the eCommerce feature is used, the following third-party cookie is set by default:

__cf_bm

• Source: The domain .prod.website-files.com, managed by Webflow, which is used to deliver website assets such as images, videos, JavaScript files, and CSS files.
• Purpose: This cookie is set by Cloudflare’s Bot Protection Service on behalf of Webflow to prevent automated access requests to the files.
• Content: According to Cloudflare’s documentation, this cookie contains encrypted session information and a timestamp. The data can only be decrypted by Cloudflare and is not used for tracking or identifying users.
• Classification: Technically necessary.

Important: Since mid-2024, Cloudflare has been a processor for Webflow and provides services such as DNS routing, bot protection, caching, security, traffic mitigation, and fraud detection. However, as of November 18, 2024, Cloudflare is not listed in Webflow’s official list of subprocessors. I raised this issue with Webflow on November 16, 2024, and hope for a prompt update of this list and any related documentation.

8.2 Additional Cookies When Using Memberships or eCommerce Features

When Webflow’s Memberships or eCommerce features are used, the following cookies may be set:

wf-csrf.sig / wf-csrf

• Purpose: Session cookies that protect visitors and the website from Cross-Site Request Forgery (CSRF) attacks.
• Classification: Technically necessary for website and user security.

__stripe_mid / __stripe_sid

• Source: Set by Stripe for fraud prevention during transactions.
• Purpose: Used by Stripe to prevent fraud and assess the risk of a transaction attempt.
• Classification: Technically necessary.

_dd_s

• Purpose: Unknown (TBD).

By default, Webflow does not set additional cookies unless optional external services or Webflow features are integrated.

8.3 Webflow Editor-Specific Cookies and Local Storage Entries

When you or your client edit the website via the Webflow Editor, the following cookies and local storage entries may appear:

Cookies:

• wf_editor_{project-name}_{project-domain}
• wf_editor_{project-name}_{project-domain}.sig
• wf_exp_uniqueId
• wf_logout
• wf_user
• wflogin
• …

Local Storage Entries:

• STATSIG_LOCAL_STORAGE_LOGGING_REQUEST
• STATSIG_LOCAL_STORAGE_STABLE_ID
• ably-transport-preference
• WebflowEditor
• webflowPersistentUIState
• WebflowEditorSession:{random-id}
• …

These cookies and entries are necessary for the editing functions of the Webflow Editor and are not visible to regular users of the website.

8.4 Custom JavaScript Solutions and Storage Mechanisms

If you write custom JavaScript or integrate external JavaScript files that store information in the user’s browser (e.g., via cookies, local storage, or session storage), consider the following:

• Consent Requirement: Any storage of data, especially user data, requires the explicit consent of the user through the implemented consent management platform.
• Examples: Even seemingly harmless features, such as storing a user’s preference for dark or light mode (if implemented via JavaScript), require consent.

8.5 Notes on Reviewing Stored Data

To check the technical status of the website from a real user’s perspective, open the website in your browser’s incognito mode and then access the developer console (Dev Tools). Under “Application,” you will find the “Cookies,” “Local Storage,” and “Session Storage” tabs, which provide an overview of all data stored in the browser.

Differences Between Local Storage and Session Storage

• Local Storage: Stores data persistently in the browser until the user manually deletes it (e.g., via browser settings).
• Session Storage: Stores data only for the current browser session. Data is deleted when the user closes the tab or browser.

9. Summary

Before I provide some useful information and answers to frequently asked questions, let me summarize the key points:

Webflow, including its Forms, Memberships, and eCommerce features, can generally be used in compliance with data protection regulations as a Platform as a Service (PaaS) under the EU-U.S. Data Privacy Framework (DPF)—but with limitations.

The following 11 aspects must be strictly observed and checked:

9.1 Webflow Components

Webflow’s native elements like YouTube, Vimeo, Google Maps embeds, Facebook Like Button, or X (Twitter) Button should only be loaded and displayed with user consent. It cannot be prevented that the user’s IP address is sent to those providers upon website access without consent if these elements are used. Below is an image illustrating the elements in question:

9.2 Fonts

Ensure that fonts are always embedded locally. Since the Munich Regional Court’s ruling on January 20, 2022, it has been clearly established that fetching Google Fonts via Google servers constitutes a violation of the right to informational self-determination. This means that by failing to locally embed fonts, the website operator transmits the user’s IP address to Google for the delivery of font files without user consent. Therefore, follow Webflow’s helpful guidance in the Site Settings under “Fonts,” which suggests uploading fonts manually (see the following screenshot):

Webflow itself offers some Google Fonts as predefined options in the Style Panel of the Webflow Designer when defining fonts (see the red-marked area in the screenshot below). If you select one of these fonts, it means that those fonts will be integrated into the website via Google Fonts’ CDN, which is not compliant with data protection regulations. Ensure that you only use fonts found under the “Custom fonts” or “Web fonts” section (see the green-marked area in the screenshot below):

Tip: If you want to use Google Fonts but don’t receive a .woff2 format from Google when downloading manually, I recommend downloading the appropriate font for free from google-fonts-helper.

9.3 Forms

If you use Webflow Forms and want to include bot protection for forms, avoid using Webflow’s integrated reCAPTCHA validation (Google reCAPTCHA V2) at all costs (see the screenshot below):

Google’s reCAPTCHA V2 “I’m not a robot” checkbox not only loads Google Fonts via Google’s CDN but also requires the user to give consent through a Consent Management Platform (CMP) for its use, rendering reCAPTCHA V2 ineffective. Instead, activate both checkboxes in the Site Settings under “Forms” in the “Spam Protection” section:

When the “Bots are being blocked” checkbox is activated, Cloudflare’s bot protection service TURNSTILE will be active after re-publishing the website.

Note: If you are responsible only for the development (not the operation) of the website, and the project uses the Webflow Forms feature shortly before publication, hide all form submissions for yourself in the Site Settings under “Forms” in the “Form submissions” section (see the screenshot below):

When activated, you will see the message “Form submission data is hidden because you told us you’re not the owner of the associated site” instead of the table containing the form data (see the screenshot below):

Note: Hiding form submissions does not exempt you as the developer from the obligation to sign a Data Processing Agreement (DPA) with your client, as you can still make the form submissions visible again at any time and thereby gain access to user personal data.

9.4 Embedding External Services with <script> or <iframe> Tags

If you integrate external services such as Cal.com / Calendly, Typeform, job portal iFrames, Elfsight solutions, Google Analytics, Google Ads, or similar (the list is virtually endless), it applies to almost 99% of these services that they are considered optional from a data protection perspective. They should always be embedded in such a way that they are only loaded and displayed after the user has given their consent via the Consent Management Platform (CMP). Personally, I have been recommending cookie-script.com (Affiliate Link) for many years due to its simple integration and API.

Explicit Recommendation: Do not rely on the “automatic blocking of third-party software” feature offered by many CMP providers. Depending on the configuration and type of third-party element integration, this is not a 100% reliable method to ensure that such elements are only loaded and displayed after the user has consented to their use. Read the CMP provider’s documentation and adapt the <script> and <iframe> tags according to their recommendations. This ensures that third-party services are truly only activated after user consent.

Example of embedding the Google Tag Manager using the documentation on blocking third-party integrations from cookie-script.com (Affiliate Link):

Before:

<script type="text/javascript">
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-XXXXXXXX-X', 'auto');
ga('send', 'pageview');
</script>

After:

<script type="text/plain" data-cookiescript="accepted" data-cookiecategory="targeting">
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-XXXXXXXX-X', 'auto');
ga('send', 'pageview');
</script>

9.5 Integration of Tools via Webflow’s Site Settings

If you are tasked with integrating tools such as Google Analytics, Google Maps, or the Meta Pixel into a Webflow website, never use the “SEO” section in the Site Settings of the Webflow project for this purpose (see the screenshot below).

Integrating tools this way prevents a Consent Management Platform (CMP) from ensuring prior user consent, as these integrations are always loaded before the CMP query. These scripts must instead be added manually in the “Custom Code” section within the <head> tag after the CMP implementation, and they may need to be modified according to the CMP documentation.

For more details, refer to “9.4 Embedding External Services with Script or iFrame Tags”.

9.6 Embedding Freely Available Scripts via Cloud Delivery Networks (CDNs)

Avoid embedding freely available scripts such as those from Finsweet Attributes, GSAP, etc., through offered CDNs (e.g., jsDelivr, unpkg, or cdnjs).

There is no legal justification for embedding files through these providers, as neither you as a developer nor your client has control over which files are provided or what happens with the transmitted user data. Whenever possible, download those JavaScript files, host them on a managed webspace, and embed them from there.

Reminder: Legislators are not concerned with whether data protection measures result in additional effort or costs; decisions are always made in favor of user rights and data protection.

For more details, see “7.1 Critical Data Protection Issues with Third-Party Scripts.”

9.7 Data Processing Agreement Between the Website Operator and Webflow

If your client hosts the Webflow website in their own Webflow workspace, inform them to sign the Webflow Data Processing Addendum (DPA).

This document fulfills the GDPR requirements for a Data Processing Agreement between the client (as the data controller) and Webflow (as the data processor).

It is crucial that this agreement is completed before any processing of personal data occurs.

9.8 Data Processing Agreement Between You as the Developer and Your Client

As a developer creating a (Webflow) website for a client, there is a high likelihood that you will have or could have access to personal data of website users at some point. This is especially true if you perform activities beyond development that involve processing user data.

Example 1: The website uses Webflow’s native form feature, and Webflow displays submitted form submissions in the Site Settings.

Example 2: You embed files hosted on your own domain and webspace into the client’s Webflow website.

Example 3: The hosted Webflow website resides in your workspace, and your client pays you to host the website via Webflow.

In these cases, the GDPR explicitly requires you to establish a Data Processing Agreement (DPA) with your client.

Fortunately, the German Federal Commissioner for Data Protection and Freedom of Information (BfDI) now provides a template for a Data Processing Agreement (DE) for download.

I recommend sending a pre-prepared agreement to your client for signing before gaining access to user data, clearly defining the services you will provide for your client.

9.9 Legal Safeguards

If you, as a developer or agency, prepare legally relevant documents (such as an imprint or privacy policy) for your clients, ensure that you explicitly disclaim liability for these documents. As a developer or agency, you are not obligated to provide legal advice. The responsibility for the legal review of the website and the use of Webflow as a Platform as a Service (PaaS) and host lies with the client.

Suggested wording for contracts or proposals:

“The client is responsible for ensuring that the use of Webflow as a PaaS (Platform as a Service) and host for the website complies with the General Data Protection Regulation (GDPR) for the processing of personal data.
If this proposal includes the creation of legally relevant documents, such as the imprint and/or privacy policy, these documents are to be regarded as templates and not as legal advice.
By confirming and signing this proposal, the client absolves the contractor of liability for these documents.”

9.10 Webflow Apps

Webflow offers a variety of third-party apps within its ecosystem that can be used to generate elements in the Webflow Designer or integrate third-party services into the website for use by actual website users. In the latter case, the app typically inserts a <script> tag into the Webflow website without the option to modify it for Consent Management Platforms (CMPs) to block the script from loading before user consent is obtained. Since these third-party services are almost always deemed optional for the website from a data protection perspective, it is essential to implement them manually rather than through the app.

If you are unsure how an app modifies the Webflow website to integrate third-party software, you will need to analyze the HTML code of the website before and after integration to identify whether and how certain tags (typically <script> and/or <iframe>) are embedded.

9.11 Webflow Analyze & Webflow Optimize

If you are considering using Webflow Analyze and/or Webflow Optimize, I recommend conducting a legal review of the implementation first. Currently, there is insufficient information about the specific user data collected and processed. I may be able to provide more detailed insights in the future.

10. Frequently Asked Questions

10.1 Do I need to implement a Consent Management Platform (CMP) only if the website uses third-party cookies?

No. A CMP is responsible for much more than just cookies. It serves as the central mechanism to allow users to decide which services/functions are used and what related processing of their personal data is performed. The question of whether a CMP is required depends not on “processing personal data yes/no” but on “technically necessary yes/no.”

10.2 How can I tell if third-party cookies are being set?

See the screenshot below, using the example of the webflow.com website opened in Google Chrome / Microsoft Edge in incognito mode: Open your browser’s developer console (Dev Tools) and go to the “Application” tab. In the “Cookies” section, select the domain under which the website is operated. Then, in the right-hand table view, you will see each cookie listed with its name, value, and other properties. To determine if a cookie is from a third party, the “Domain” column is crucial. If a domain other than webflow.com or .webflow.com is listed, it is a third-party cookie (highlighted in yellow by Google Chrome).

10.3 Do user consents or rejections regarding the use of cookies need to be documented/stored?

Quote from eRecht24’s FAQ on the webinar “Legally Secure Website 2024” from January 17, 2024, in response to the question “Do consents/objections via the consent tool need to be stored? What is recommended here?”:

“In general, consents are stored via consent tools. However, it is sufficient to demonstrate that a functioning consent mechanism exists on the website. Proof of cookie consents has not yet been the subject of legal disputes."

Following eRecht24’s statement, proof of a technically functioning consent mechanism suffices, and storing user consents is not required. Common Consent Management Platforms already store consents (anonymized) or offer this feature as an “addon.”

10.4 Do I need to sign a Data Processing Agreement with my client?

See point “9.8 Data Processing Agreement Between You as the Developer and Your Client”

10.5 Do I need to integrate a Consent Management Platform (CMP) into a Webflow website if I haven’t embedded third-party solutions?

No, not necessarily. Since the cookie __cf_bm set by Cloudflare on behalf of Webflow is technically necessary, providing information about this cookie in the privacy policy is sufficient. However, if you store user preferences/information using JavaScript in the form of cookies or entries in session or local storage, you need a CMP to allow users to consent or decline.

For more details, see point “8.4 Custom JavaScript Solutions and Storage Mechanisms.”

10.6 Is a checkbox in contact forms to confirm acknowledgment of the privacy policy mandatory?

No. On the contrary, the GDPR emphasizes the principle of data minimization, and consent for data processing according to the privacy policy should not be requested separately.

10.7 Do I need to obtain user consent to load YouTube videos, even if I embed them with “enhanced privacy mode”?

Yes, because the user’s IP address is transmitted to YouTube without consent. From a data protection perspective, the video can also be embedded without using YouTube, which is why embedding via YouTube is considered optional.

10.8 Do I need to obtain user consent to load Vimeo videos, even if I use the [dnt='true'] (Do Not Track) attribute?

Yes, because the user’s IP address is transmitted to Vimeo without consent, even with the “Do Not Track” attribute. From a data protection perspective, the video can also be embedded without using Vimeo, which is why embedding via Vimeo is considered optional.

10.9 I want to integrate freely available solutions like Finsweet Attribute solutions, GSAP products, Lenis, etc., into my website. Can I use the offered <script>- tags that load the necessary JavaScript from a Cloud Delivery Network (CDN) provider like jsDelivr or Cloudfront?

No. In European data protection circles, the use of CDNs is generally controversial, and the legal situation is relatively “unclear.” However, the use of a CDN must comply with the general legal requirements of local data protection regulations, such as signing a Data Processing Agreement (DPA).

If you embed files from third-party sources in your website without a contractual relationship, neither you as the developer nor your client can control the files being fetched or the processing of the users’ IP addresses, which are transmitted to the CDN provider during retrieval. From a data protection perspective, this constitutes an intentional illegal transfer of personal data without authorization.

I strongly recommend downloading the files from the CDN and hosting them locally on a client-owned webspace and embedding them from there.

Reminder: Legislators are not concerned about whether data protection measures involve additional effort or costs; decisions are always made in favor of users and data protection. The “legitimate interest” under Recital 47 of the GDPR will not hold in this case, as these files can also be downloaded and hosted locally.

For more information, see the important note in “7.1 Critical Data Protection Issues with Third-Party Scripts.”

10.10 Do I need to obtain user consent through a CMP before embedding Google Tag Manager (GTM)?

There is no definitive answer to this question, as using Google Tag Manager (GTM) without prior consent is legally disputed. Ultimately, you must decide if and to what extent you want to use GTM. It is clear, however, that GTM is a powerful tool that allows users without significant coding knowledge to load third-party services or custom JavaScript. GTM acts as a container that manages external resources and operates independently of the website itself.

A GTM implementation without linked services (so-called “tags”) does not set cookies. However, it necessarily processes the user’s IP address, as this is required to determine where the embedded tags should be delivered. For this reason, a Data Processing Agreement (DPA) between the website operator and Google is mandatory, even if GTM is used alone.

Case Study 1: Minimal Use of GTM
Suppose you use GTM solely to integrate Google Analytics, the Meta Pixel, or the LinkedIn Pixel into the website. Data protection advocates often cite the principle of data minimization under Article 5(1)(c) GDPR. In this scenario, GTM is viewed as an unnecessary and inappropriate “bridge” in data processing. After all, these services could also be embedded directly into the website without requiring the user’s personal data to be additionally processed by GTM.

If a user files a complaint with a data protection authority and claims a violation of the principle of data minimization, data protection experts believe the authority would side with the user. The website operator would then be required to embed the services without GTM and may be liable for damages.

Case Study 2: Advanced Use of GTM
In this scenario, GTM is used by marketing agencies or teams of the website operator to manage and control a variety of additional services. GTM could also be configured to allow the website operator’s partners to make changes to the GTM container without having direct access to the critical infrastructure of the website.

Regardless of the case, optional services embedded via GTM must obtain prior user consent through a Consent Management Platform (CMP) before they can be activated.

The difference from Case Study 1 lies in the argumentation: The website operator could invoke “legitimate interests” under Article 6(1)(f) GDPR. Data protection experts believe this argument would likely hold up in court but caution that there is no legal certainty for this claim.

Risk Assessment
Using Google Tag Manager—whether with or without tags—thus carries a data protection risk. While the use of GTM in Case Study 1 would most likely be considered non-compliant, Case Study 2 offers a stronger legal basis for its use. Nevertheless, the use of GTM without prior user consent remains controversial, and the decision for or against GTM should always be carefully considered.

Summary

• GTM does not set cookies without connected tags but does process users’ IP addresses, requiring a Data Processing Agreement (DPA) with Google.
• Case Study 1: Using GTM for simple services like Google Analytics or Meta Pixel is generally considered unnecessary and non-compliant, as these services could be embedded directly without GTM.
• Case Study 2: Advanced use of GTM can be justified by legitimate interests but still carries legal uncertainties.
• Optional services embedded via GTM must be activated only after obtaining user consent through a CMP.
• Using GTM without prior consent poses a data protection risk and should only be done after careful consideration.

10.11 Should I integrate the Consent Management Platform (CMP) into the website using Google Tag Manager (GTM)?

I advise against it. Even though major CMP providers often provide very detailed instructions for this, GTM is primarily a marketing tool, which means:

1. It is often blocked by ad blockers, resulting in no GTM and therefore no Consent Management.
2. Using GTM without prior user consent via a CMP is considered a legal risk (see the answer to question “10.10 Do I need to obtain user consent through a CMP before embedding Google Tag Manager (GTM)?”).

10.12 Can I prevent the integration of the jQuery JavaScript library via Cloudfront’s CDN into a Webflow project?

Yes, it is possible to prevent the integration of jQuery via Cloudfront’s CDN in a Webflow project. However, this may require significant adjustments to your client’s network and security infrastructure. The solution involves using Cloudflare as the DNS provider for the website’s domain and performing a “Hot Replacement” using a Cloudflare Worker.

Setting up Cloudflare as the DNS Provider
To use Cloudflare, replace the nameservers of your client’s domain provider with the nameservers provided by Cloudflare. Cloudflare will then handle the DNS routing for the domain. As of today, this incurs no costs for your client, as Cloudflare offers its basic service free of charge.

Once this very simple setup process with Cloudflare is complete, you or your client can create a Cloudflare Worker and add the following code to it:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  // The URL to be replaced
  const targetUrl = 'https://{{SITE_ID}}.cloudfront.net/js/jquery-3.5.1.min';
  // The URL to be used instead
  const newUrl = 'https://subdomain.clientdomain.com/jquery-3.5.1.min.js';

  // Create a new instance of the HTMLRewriter
  let rewriter = new HTMLRewriter()
    .on('script[src]', {
      element(element) {
        const src = element.getAttribute('src');
        // Check whether the src attribute begins with the target URL
        if (src.startsWith(targetUrl)) {
          // Replace the src attribute with the new URL
          element.setAttribute('src', newUrl);
        }
      }
    });

  // Get the original answer
  const response = await fetch(request);

  // Apply the HTMLRewriter to the answer
  return rewriter.transform(response);
}

Notes on the Code:

1. Configure targetUrl:
   Copy the URL from the src attribute of the <script> tag that loads jQuery from Cloudfront and assign it as the value of the targetUrl variable.

2. Host jQuery Locally:
   Download the jQuery file from the targetUrl and store it on a publicly accessible webspace owned by your client.
   Alternatively, your client can use a Cloudflare R2 Bucket, which is free up to a certain traffic limit.

3. Configure newUrl:
   Assign the URL of the locally hosted jQuery file as the value of the newUrl variable.

After making these adjustments, click “Deploy” to save the worker.

Activate the Cloudflare Worker
Navigate to the “Settings” tab of the worker and go to the “Domains & Routes” section.

Add the client’s domain in the following format:

*clientdomain.com/*

Done.

Process of the Hot-Replacement
After activating the worker, the following will happen when the website is accessed:

1. The user accesses the website via the client’s domain, which sends their IP address to Cloudflare as the DNS provider.
2. Cloudflare retrieves the HTML file of the website from the Webflow servers.
3. The Cloudflare Worker scans the HTML code for a <script> tag whose src attribute matches the URL in targetUrl.
4. If a matching <script> tag is found, the worker replaces the URL in the src attribute with the new URL from newUrl.
5. Cloudflare serves the modified HTML file to the user.

This entire process occurs on the server level and is therefore invisible to the user. The speed of this operation depends on Cloudflare’s infrastructure rather than the user’s internet connection.

Important Note:
Since Cloudflare processes at least the user’s IP address on behalf of the website operator (your client), your client must sign a Data Processing Agreement (DPA) with Cloudflare.

10.13 My client asks how Element X from Provider Y must be integrated into the website to comply with GDPR. How should I handle this situation?

In this situation, caution is essential because, as a developer, you are not allowed to provide legal advice unless you are a lawyer. However, you can share recommendations and your experience with your client—with a clear disclaimer that these are not legally binding since you are not a legal expert.

Recommended Approach:

1. Clarify Your Limitations:
   Inform your client that while you consider data protection aspects to the best of your knowledge, you cannot provide legal guarantees.

2. Recommend Legal Review:
   Emphasize that legal review and all relevant decisions must be made by your client. If in doubt, your client should consult a legal expert.

3. Set Expectations Early:
   Ideally, your proposal or contract should clearly state that you do not take responsibility for the legal evaluation of data protection measures. Refer to “9.9 Legal Safeguards” for more details.

4. Document Your Recommendations:
   Clearly note the recommendations you provide and explicitly state that they do not constitute legal advice. This protects you in case of misunderstandings or disputes.

10.14 My client wants me to implement measures that are not GDPR-compliant despite my professional recommendation. How should I handle this situation?

This situation requires extra care because, as a developer, you are liable for ensuring that your work complies with legal requirements. Contracts for website development typically fall under work contract law, meaning you are obligated to deliver a product that is free of defects and complies with applicable laws.

Recommended Approach:

1. Clarify the Legal Risks:
   Explain to your client why the requested implementation is not GDPR-compliant and outline the potential legal consequences. Stress that the responsibility for this decision lies entirely with the client.

2. Request Written Confirmation:
   If your client insists on the implementation despite your professional warning, obtain written confirmation. This should clearly state that the client insists on the implementation against your advice and takes full responsibility for any legal consequences.

3. Consider Potential Consequences:
   Evaluate whether the collaboration remains viable in such cases. Implementing non-compliant measures could harm your reputation or legal standing in the long term.

10.15 Where can I or my client download/sign the Data Processing Agreement (DPA)?

On Webflow’s page for the so-called “Data Processing Addendum,” there is a link to download the Data Processing Addendum via DocuSign provided by Webflow.

→ GUIDE END ←

A request to you and everyone: If you have a question, problem, or request related to this guide, please do not send me a private message. Instead, leave a comment under this post so that others can benefit from potential solutions.

If you’d like to support my work for the community, you can do so by becoming a member via my Patreon account: patreon.com/denniskarg

A quick note on my own behalf: If you’re a German-speaking Webflow user, the Webflow DACH Community with over 1,600 members warmly welcomes you on Discord and Facebook.

I hope this guide was helpful to you.

Dennis Karg (Patreon / X-Twitter / LinkedIn / Webflow)

[Marius1989 (Marius)]

Thank you so much for this incredibly valuable contribution to the [german] community.

[maxl (max)]

Vielen Dank für deine Mühe! Super hilfreich!

[Amelie1 (Amelie)]

Absolut klasse! Danke für deine Mühe @Dennis_K !

[salsomb (Marvin)]

Mega geil @Dennis_K ! Ich habe leider bei meiner Recherche echt extrem viel Zeit reinstecken müssen, kenne mittlerweile die Stellschrauben (u.a. auch dank dir) und habe trotzdem weiterhin ein ungutes Gefühl beim Hosting über Webflow, da trotz aller Maßnahmen die Rechtslage noch immer nicht vollständig geklärt ist.

Was ich absolut nicht kapiere ist, warum man bei Webflow Code nur an das ENDE des Headers einfügen kann. Das Problem ist, dass Integrationen wie bspw. Google Analytics & FB Pixel somit VOR dem eingefügten Cookiescript am Ende des Header ausgeführt werden und somit die Cookies schon gesetzt werden, bevor überhaupt die Einwilligung erteilt wurde. Das macht das Cookie Opt-In meiner Ansicht nach praktisch wirkungslos und auch nicht DSGVO-konform, auch wenn danach die Cookies vom User abgelehnt werden. Wie seht ihr das?

Das dürfte seitens Webflow doch wirklich kein Problem sein, einen Code an den ANFANG des Headers einzufügen, oder?

[markusbieler]

Hallo Marvin,

wenn du Google Analytics etc manuell mittels embed einfügst und nicht die project settings nutzt, hast du die Möglichkeit den Code für diese Marketing Tools als .txt einzufügen. Erst nach der Zustimmung des Nutzers ändert Cookiescript die Dateiendung und aktiviert somit das jeweilige Tool.

[Marius1989 (Marius)]

Das würde mich auch brennend interessieren.
Gibt es einen Dienst, den ihr regelmäßig nutzt und sich bei euch etabliert hat?
Kontaktformulare sind essenziell und Tipps für eine adäquate und DSGVO-konforme Lösung wären wünschenswert.

[Dennis_K (Dennis Karg)]

Moin @Marius1989,

wir nutzen seit über einem Jahr ausschließlich den selbst gehosteten Form Processor von Tectite für und bei unseren Kunden. Das PHP Skript ist äußerst mächtig und bietet unzählige Möglichkeiten, unter anderem auch File Uploads.

Der größte Vorteil: Es werden keine Übermittelten Daten auf dem Server des Skripts gespeichert (#DSGVO), sondern direkt an den Empfänger weitergeleitet. Uploaded Files werden nur temporär gespeichert, um diese dann ebenfalls direkt weiterzuleiten.

Handhaben kannst du das so, dass du für deine eigene Domain z.B. eine Subdomain wie assets.deinedomain.de anlegst und dort alle Dateien ablegst, die auf den Seiten deiner Kunden benötigt/verwendet werden. Um die Organisation zu vereinfachen, erstellst du noch Unterordner für jeden Kunden e.g. dogado | Alles für dein digitales Business

Ich hoffe, das hilft dir weiter.

@markusbieler bist du so lieb und kannst zu dem Embed von externen Skripts als .txt einen kurzen Guide schreiben?

Liebe Grüße

Dennis von Vibrand Design

[Marius1989 (Marius)]

Vielen Dank für die ausführliche Information und weiteren Tipps für die Integration eines DSGVO-konformen Kontaktformulars.

Nachdem ich mich einige Zeit mit dem Script auseinander gesetzt habe, sehe ich das als eine super Lösung - sobald man das ganze einmal aufgesetzt hat und es funktioniert.

[Schuschi_Eyes (Martin S.)]

Hey echt toll, dass du dir für die Community diese riesen Mühe gemacht hast! Das erspart hier einigen Leuten viele Stunden Recherchearbeit und viele Nerven

Hoffen wir, dass das ganze für uns Entwickler irgendwann wieder etwas einfacher wird in Europa - ohne dass dabei auf Datenschutz verzichtet werden muss.

[MartyL]

@Dennis_K

Nutze NICHT die von Webflow angebotene Funktion für Kontaktformulare, sondern immer eine eigene Lösung.

Gibt es hier eine besondere Begründung? Solange das mit einem korrekten opt-in geregelt ist und der Punkt in der Datenschutzerklärung steht scheint das i. O. zu sein.

[Dennis_K (Dennis Karg)]

Hey @MartyL,

grundsätzlich hast du Recht, solang der Nutzer zustimmt, könnten wir theoretisch alles tun, allerdings sind das 2 paar Schuhe. Aktuell wird von der EU das Datenschutzniveau außereuropäischer Unternehmen durch die Kippung des EU-US Privacy Shields erstmal nicht als angemessen angesehen.
Daher wird jeder Datenschützer sagen: “Ist ja schön und gut, dass der Nutzer der Verarbeitung auf ausländischen Servern von ausländischen Unternehmen zugestimmt hat, aber dennoch kann er sein Durchsetzungsrecht nicht geltend machen und deutsches Recht zum Schutz seiner Daten anwenden.”

Deshalb kann ich persönlich nur davon abraten, trotz ausdrücklicher Zustimmung des Nutzers, das Formular zu nutzen, solang die rechtliche Grundlage nicht vorhanden bzw. so unklar ist, wie jetzt.

[crstn (Carsten Jaksch)]

Facebook als exklusive Plattform für eine Community auch nur in Erwägung zu ziehen, ist eine schlechte Idee.

[Dennis_K (Dennis Karg)]

Hallo @crstn , welche Plattform würdest du denn gerne nutzen, um dich mit einer Community zu verknüpfen?

[crstn (Carsten Jaksch)]

Jede Plattform, dessen Beiträge gänzlich ohne Anmeldung zugänglich sind und ihre Mitglieder nicht willkürlich sperrt ist ein optimaler Kandidat. Letzteres ist aber am wichtigsten: kein Ausschluss. Das macht Facebook sehr gerne.

Und man sollte nicht exklusiv zu einer Plattform gehen.

Als eine Art Forum kommt Reddit in Frage. Als Chat Telegram, Slack oder andere Plattformen für (Team-)Chats. Facebook kann ja gerne bleiben, aber nicht exklusiv.

Und wenn man es ernst meint, noch eine Website als zentrale Anlaufstelle — natürlich mit Webflow erstellt.

So eine Community ist nicht nur für interessierte Nutzer von Webflow da. Sie stärkt die Interessen der deutschen Gemeinschaft gegenüber dem Anbieter und fördert die Adaption von Webflow in Deutschland.

Vielleicht werden auch kritische Themen wie die DSGVO zukünftig eher in Angriff genommen, wenn am anderen Ende ein großer Haufen Geld in Form einer starken Community Druck ausübt — statt vereinzelter Foren- und Wishlist-Beiträge verzweifelter Nutzer. Kann man schon etwas größer aufziehen, wenn du mich fragst.

[Dennis_K (Dennis Karg)]

Hallo Carsten,

ich verstehe deine Gedanken. Eine Community muss jedoch irgendwo beginnen sich zu entwickeln und die erste Plattform dafür war eben Facebook, da sich bei Facebook ebenfalls die offizielle Webflow Community Gruppe befindet.
Seit Anfang April ist die deutsche Webflow Community auch mit einem Discord Community Server vertreten und ich lade dich herzlich ein, dich dort mit der Community auszutauschen.

Hier der Link zum Discord Server der deutschen Webflow Community: Discord

Beste Grüße und einen erfolgreichen Start in die Woche für dich!
Dennis von Vibrand Design

[elolitta (Nora Goerne)]

Hallo! Danke, das ist wirklich sehr hilfreich!

Wie sieht es aus, wenn man Google Fonts importiert hat? Müsste dazu auch noch etwas eingefügt werden bzw. ein Abkommen unterzeichnet werden?

Was mir auch noch nicht ganz klar ist, sind die Cookies. Wenn ich es richtig verstehe, setzt Webflow keine Cookies oder? D.h. einen Cookie Banner bräuchte man nicht, wenn man keine anderen Dienste einbietet, über welche Cookies gespeichert werden oder?

[Dennis_K (Dennis Karg)]

Hey @elolitta ,

wie das bei Google Fonts im speziellen aussieht, kann ich dir leider nicht sagen. Grundsätzlich raten Anwählte aufgrund der unsicheren Rechtslage davon ab, Webfonts extern einzubinden.
Die sicherste Variante wäre daher: Fonts herunterladen und manuell hochladen.

Das hast du richtig verstanden, Webflow selbst setzt keine Cookies auf deiner Website. Wenn du also keine Dienste eingebunden hast, die Daten verarbeiten, nutzt du dementsprechend auch keine Cookies, dessen Zustimmung du einholen musst.
Lediglich auf der Staging Domain .webflow.io werden Cookies seitens Webflow gesetzt, die aber eher funktionaler Natur sind.

Beste Grüße
Dennis

[elolitta (Nora Goerne)]

Vielen Dank Dennis!

Okay, dann habe ich das mit den Cookies ja zumindest richtig gemacht.

Zu den Google Fonts - was genau meinst du mit Fonts herunterladen und manuell hochladen? Also wenn ich einen Google Font unter Settings auf diese Weise hinzufüge, fällt das unter extern einbinden? Und wenn ja, müsste ich sonst diese Google Fonts herunterladen und manuell unter “Custom Fonts” hochladen? Oder sollte man am besten gar keine Google Fonts benutzen?

Sorry, ich habe schon ein paar Monate nicht mehr mit Webflow gearbeitet.

[Dennis_K (Dennis Karg)]

Hey Nora @elolitta ,

korrekt, das zählt zu extern einbinden. Bei dieser Art der Font Einbindung werden die Fonts von den Google Server angefragt und abgerufen (zwangsläufig wird also die IP des Nutzers an Google übermittelt).

Genau, um das zu umgehen lädst du die gewünschten Fonts und deren Variationen direkt von fonts.google.com herunter und lädst sie als Custom Fonts hoch.
Google Fonts ist lediglich ein komfortabler Service seitens Google, der WebentwicklerInnen spielend einfach ermöglicht, die dort gelisteten Open Source Fonts in eigene Projekte einzubinden.

Beste Grüße
Dennis