Cloudflare Browser Run: Guardrails für sichere Kunden-Reviews

Am 14. September 2026 hat Cloudflare Browser Run zwei Kontrollmechanismen eingeführt, die den Einsatz von Browserautomatisierung für Kunden verändern: Eine Sitzung lässt sich auf eine Liste freigegebener Hostnamen begrenzen, während Prüfer über Live View zusehen können, ohne selbst eingreifen zu dürfen. Bis zu 50 Hostnamen können direkt hinterlegt oder bis zu vier gemeinsam genutzte Domain-Sets eingebunden werden. Entscheidend ist jedoch nicht die Länge der Liste, sondern die klar definierte Betriebsgrenze.

Cloudflare Browser Run setzt zwei getrennte Grenzen

Eine Sitzung in Cloudflare Browser Run ist eine entfernte Chrome-Instanz. Gesteuert wird sie per Code über Puppeteer, Playwright oder das Chrome DevTools Protocol, meist kurz CDP genannt.

Die neuen Sitzungs-Guardrails legen fest, welche Ziel-Hostnamen dieser Browser über HTTP oder HTTPS anfragen darf. Die Richtlinie wird beim Start der Sitzung festgeschrieben und bleibt während ihrer gesamten Laufzeit bestehen.

Die neue Read-only-Einstellung für Live View erfüllt eine andere Aufgabe. Sie bestimmt, was eine Person über einen einzelnen erzeugten Ansichtslink tun darf. Ein Read-only-Betrachter sieht die Sitzung, kann aber weder navigieren noch tippen, klicken oder JavaScript ausführen.

Diese Trennung ist wichtig. Die Automatisierung behält die Kontrolle über den Browser, der Prüfer beobachtet lediglich. Zugleich bleiben die HTTP- und HTTPS-Anfragen des Browsers innerhalb der Freigabeliste der Sitzung – unabhängig davon, welche Live-View-Verbindung gerade geöffnet ist.

So wird Browserautomatisierung zum Kundenfreigabe-Workflow

Ein typisches Szenario: Eine Agentur erstellt einen Bericht in der Web-App eines Kunden. Der Browser benötigt den primären Hostnamen des Kunden, einen Authentifizierungs-Host, eine API, einen Font-Host und möglicherweise ein Bild-CDN. Gleichzeitig möchte der Kunde den Ablauf sehen, bevor er das Ergebnis freigibt.

Beide Anforderungen lassen sich nun als getrennte Entscheidungen behandeln:

1. Die technische Leitung genehmigt die Ziele, die für die Sitzung erforderlich sind.
2. Der Kunde erhält eine Read-only-URL für Live View und verfolgt den laufenden Auftrag.

Der Prüfer bekommt keinen interaktiven Browser. Der Auftrag bekommt keine offene Zielliste. Das schafft eine sauberere Übergabe, als einen gemeinsam genutzten Browserlink gleichzeitig als Vorführwerkzeug und als Entscheidung über Zugriffsrechte zu behandeln.

Ein vollständiges Sicherheitssystem entsteht dadurch dennoch nicht. Cloudflare dokumentiert Hostname-Regeln für HTTP- und HTTPS-Anfragen; als universelle Netzwerk-Sandbox sollte die Funktion deshalb nicht beschrieben werden. Außerdem enthält eine Live-View-URL ein signiertes JWT und ist damit in ihrer vollständigen Form ein Zugangsschlüssel. Read-only verhindert Interaktionen, legt aber weiterhin alles offen, was auf der Seite erscheint.

Der eigentliche Aufwand steckt in der Asset-Liste

Der naheliegende Hostname reicht für eine vollständige Seite nur selten aus.

Eine produktive Website kann beim Login weiterleiten, eine separate API aufrufen sowie Skripte, Bilder und Fonts von jeweils anderen Hosts laden. Cloudflare verlangt, all diese Abhängigkeiten einzutragen. Fehlt eine davon, antwortet der Browser auf die betreffende Anfrage mit 403; in den Response-Headern stehen dann cf-mitigated: guardrails und cf-brapi-guardrails-reason: not-in-allowlist.

Damit wird die Pflege der Freigabeliste zu einem echten Teil der Bereitstellungskosten. Jedes Redesign beim Kunden, jeder Wechsel des Identitätsanbieters, des Analytics-Anbieters oder des CDN kann eine Richtlinienänderung und einen neuen Validierungslauf auslösen. Eine seriöse, universell gültige Aufwandszahl gibt es dafür nicht. Gemessen werden muss am eigenen Auftragsbestand.

Cloudflare bietet zwei Wege, die Liste zu übergeben:

• allowedDomains ist die direkte Variante und akzeptiert beim Sitzungsstart bis zu 50 Hostname-Muster.
• allowedDomainSets akzeptiert bis zu vier gemeinsam genutzte Listen. Dazu gehören das Cloudflare-Set common-cdns oder HTTPS-URLs, die eine einfache Textliste mit Hostnamen liefern.

Eine gemeinsame Liste ist praktisch, wenn viele Kundenaufträge dieselben freigegebenen Dienste benötigen. Allerdings gelten zeitliche Regeln: Cloudflare speichert eine gehostete Liste bis zu einer Stunde im Cache. Eine Änderung wirkt sich erst auf Sitzungen aus, die nach dem Einlesen der aktualisierten Liste gestartet werden. Die Richtlinie einer laufenden Sitzung ändert sich nie im Hintergrund.

Bei common-cdns kommt ein weiterer Zielkonflikt hinzu: Cloudflare pflegt das Set und kann es im Laufe der Zeit ändern. Das spart Listenpflege, ist aber keine unveränderliche Freigabeliste. Wenn ein Vertrag oder Audit einen stabilen Bestand an Zielen verlangt, sind explizite Hostnamen oder eine selbst gehostete Liste die bessere Wahl.

Vier Teams, die Cloudflare Browser Run jetzt gezielt einsetzen können

Technische Agenturleitung: Freigabe und Bedienung trennen

Die App des Kunden und ihre erforderlichen Abhängigkeiten werden freigegeben, der Browserauftrag wird gestartet und anschließend ein Read-only-Link für Live View an Account-Verantwortliche oder Prüfer auf Kundenseite ausgegeben. So lässt sich beobachten, wie die Nachweise entstehen, ohne in die App zu klicken oder den Lauf zu verändern. Der Vorteil ist ein Prüfschritt, der nicht unbemerkt zur Übergabe der Bedienung wird.

SaaS-Gründer: Ein eigenständiges PDF bleibt eigenständig

Wer bereits Screenshots oder PDFs aus vertrauenswürdigem Inline-HTML erzeugt, kann die Sitzung mit einem leeren allowedDomains-Array und ohne Domain-Sets starten. Das HTML wird weiterhin gerendert, kann über HTTP oder HTTPS aber weder externe APIs und Skripte noch Bilder oder Fonts abrufen. Daraus entsteht eine einfachere, überprüfbare Aussage: Dieser Renderlauf hat keine externen Webinhalte angefragt.

Für Quick Actions steht genau diese Kontrolle nicht zur Verfügung. Das gilt auch für die Endpunkte, die häufig als Abkürzung für Screenshots und PDFs verwendet werden. Erforderlich ist eine Browser Session über Puppeteer, Playwright oder CDP.

Plattformteam: Eine zentrale Abhängigkeitsrichtlinie pflegen

Eine einfache Textliste wird über HTTPS bereitgestellt, wobei jede Zeile genau ein Hostname-Muster enthält. Die URL kommt anschließend in allowedDomainSets. Mehrere Komponenten, die Sitzungen starten, können dieselbe Liste verwenden. Der Vorteil ist eine zentrale Pflegestelle – verbunden mit der wichtigen Regel, dass bereits eine ungültige Zeile zur Ablehnung der gesamten gehosteten Liste führt.

Sicherheitsprüfung: Einen fehlgeschlagenen Test verlangen

Die Konfiguration allein reicht als Nachweis nicht. Zusätzlich sollte eine Anfrage an einen nicht freigegebenen Hostnamen gesendet und anschließend der Status 403 samt den beiden Guardrail-Headern in der Prüfdokumentation gespeichert werden. So belegt der Negativpfad seine Funktion; ein Screenshot eines plausibel aussehenden Objekts tut das nicht.

Eine geschützte Review-Sitzung einrichten

Hier ist ein technischer Ablauf nötig, weil die Funktion beim Erstellen der Sitzung greift. Der folgende Code stammt aus den Cloudflare-Seiten, die für diesen Beitrag ausgewertet wurden.

1. 1

   Kompatiblen Client installieren und Browser binden

   Für Guardrails verlangt Cloudflare @cloudflare/puppeteer ab Version 1.4.0. Der Installationsbefehl für Puppeteer lautet:

   npm i -D @cloudflare/puppeteer

   Der Worker braucht außerdem eine Browser-Bindung. Im Wrangler-Beispiel von Cloudflare heißt sie MYBROWSER:

   {
   	"$schema": "./node_modules/wrangler/config-schema.json",
   	"name": "browser-rendering",
   	"main": "src/index.ts",
   	"workers_dev": true,
   	"compatibility_flags": ["nodejs_compat_v2"],
   	"browser": {
   		"binding": "MYBROWSER"
   	}
   }

   Die installierte Paketversion sollte ausdrücklich geprüft werden. Die ältere Puppeteer-Übersicht bezeichnet noch 1.1.0 als aktuell, die neuere Guardrails-Seite verlangt jedoch 1.4.0 oder höher. Für diese Funktion gilt die neuere Anforderung.

2. 2

   Sitzung mit Zielrichtlinie starten

   Im geschützten Puppeteer-Beispiel von Cloudflare sind die Apex-Domain, ihre Subdomains und das gemeinsam genutzte Set common-cdns erlaubt:

   import puppeteer from "@cloudflare/puppeteer";
   
   export async function startGuardedSession(env) {
   	const browser = await puppeteer.launch(env.MYBROWSER, {
   		guardrails: {
   			allowedDomains: ["example.com", "*.example.com"],
   			allowedDomainSets: ["common-cdns"],
   		},
   	});
   
   	return browser;
   }

   Die Beispielwerte sollten erst ersetzt werden, nachdem Weiterleitungen, APIs, Skripte, Bilder und Fonts der Seite vollständig erfasst wurden. Wichtig: *.example.com schließt example.com nicht ein. Deshalb stehen beide Einträge in der Liste.

3. 3

   Blockierung eines nicht freigegebenen Hosts nachweisen

   Eine Anfrage geht gezielt an einen Hostnamen außerhalb der Liste. Erwartet wird HTTP 403 mit cf-mitigated: guardrails und cf-brapi-guardrails-reason: not-in-allowlist. Zusätzlich muss die freigegebene Seite über den vollständigen Login- und Renderpfad getestet werden. Der Negativtest belegt die Grenze, der Positivtest die weitere Funktionsfähigkeit des Auftrags.

4. 4

   Read-only-Link für die Prüfung erzeugen

   Sobald die Sitzungs-ID vorliegt, erzeugt das REST-Beispiel von Cloudflare eine Tab-Ansicht, in der der Betrachter nicht interagieren kann:

   curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/browser-rendering/devtools/browser/$SESSION_ID/live_view" \
   	--request POST \
   	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
   	--json '{
   		"mode": "tab",
   		"guardrails": {
   			"mode": "readonly"
   		}
   	}'

   Diese URL sollte in vertrauenswürdigem serverseitigem Code erzeugt und über einen vertrauenswürdigen Kanal geteilt werden. Standardmäßig muss die Verbindung innerhalb von fünf Minuten beginnen. expiresInMs lässt sich auf mindestens 60,000 Millisekunden oder höchstens 3,600,000 Millisekunden festlegen, also eine Stunde.

Das mehrfach verwendete Wort guardrails kann hier irritieren. Beim Sitzungsstart enthält es allowedDomains und steuert die Ziele. In der Anfrage für die Live-View-URL enthält es mode: readonly und steuert genau diesen Betrachter. Wer beide Grenzen benötigt, muss auch beide Einstellungen setzen.

Guardrails können den Auftrag in ein anderes Kostenmodell verschieben

In der aktuellen Preisstruktur von Browser Run berechnet Cloudflare keine eigene Position für jeden Eintrag der Freigabeliste. Kosten entstehen, wenn sich die Integrationsmethode ändert.

Quick Actions werden ausschließlich nach Browserstunden abgerechnet, können diese Guardrails aber nicht verwenden. Browser Sessions unterstützen Guardrails und werden nach Browserstunden plus gleichzeitigen Browsern berechnet. Muss ein bisher über einen Kurz-Endpunkt laufender PDF- oder Screenshot-Workflow nun Hostnamen einschränken, verändert der Wechsel zu Puppeteer, Playwright oder CDP sowohl die Implementierung als auch das Kostenmodell.

Workers Paid umfasst 10 Browserstunden pro Monat und 10 gleichzeitige Browser. Zusätzliche Browserzeit kostet $0.09 pro Stunde. Zusätzliche Parallelität kostet $2.00 pro Browser, berechnet nach dem monatlichen Durchschnitt der täglichen Spitzenwerte.

Für die Planung eignet sich diese Formel:

extra usage cost = max(0, browser hours - 10) × $0.09 + max(0, average daily peak browsers - 10) × $2.00

Im Beispiel von Cloudflare fallen 50 Browserstunden bei durchschnittlich 15 gleichzeitigen Browsern an. Daraus ergeben sich $3.60 für 40 zusätzliche Stunden und weitere $10.00 für fünf zusätzliche Browser, zusammen also $13.60 an zusätzlichen Nutzungsgebühren. Das ist keine Guardrail-Gebühr, sondern die Rechnung für den Browser-Session-Pfad, der Guardrails unterstützt.

Workers Free enthält 10 Browserminuten pro Tag und drei gleichzeitige Browser. Für einen kleinen Machbarkeitsnachweis kann das genügen, für einen Kunden-Workflow mit wiederholten Prüfläufen bleibt jedoch wenig Spielraum.

Wer Browser Sessions bereits nutzt, wechselt nicht in andere Abrechnungskategorien. Die neuen Kosten sind vor allem operativ: Asset-Hosts erfassen, erlaubte und blockierte Pfade testen und die Liste aktuell halten. Für den Vergleich verwalteter Browseransätze ordnet der umfassendere Leitfaden zu Browsern für KI-Agenten diese Nutzungspositionen ein.

Wo der Ansatz weiterhin scheitern kann

Das naheliegendste Fehlerszenario: Eine Seite funktioniert in der Entwicklung, verliert nach Aktivierung der Freigabeliste aber einen Font, ein Bild, eine Login-Weiterleitung oder einen API-Aufruf. Ein zu weit gefasster Platzhalter kann den Fehler zwar verschwinden lassen, schwächt jedoch genau die Grenze, die eigentlich geschaffen werden sollte.

Cloudflare erlaubt einen Platzhalter pro Hostname-Muster. Für Subdomains ist *.example.com die bessere Wahl; die Hauptdomain wird separat aufgeführt. Ein Präfixmuster wie *example.com kann auch eine ähnlich aussehende Domain wie evilexample.com erfassen und ist daher die falsche Abkürzung für eine eng gefasste Kundenrichtlinie.

Auch Read-only Live View hat eine klare Grenze. Geschützt wird nur eine einzelne Betrachterverbindung – weder die Sitzung vor ihrem Betreiber, noch wird eine andere Verbindung daran gehindert, sie zu steuern. Puppeteer und Playwright können die Read-only-Verbindung nicht bedienen, weil die benötigten Befehle blockiert werden. Für Prüfer ist das sinnvoll, als Zugangsschlüssel für die Automatisierung ist es unbrauchbar – genau so soll es sein.

Quick Actions und Kitesurf bleiben von der Guardrails-Funktion ausgeschlossen. Teams mit einer dieser beiden Varianten sind erst betroffen, wenn ihnen die Hostname-Grenze einen Wechsel des Integrationspfads wert ist.

Der nächste Schritt am Montag

Für den Pilotversuch eignet sich ein echter Kundenauftrag mit einem stabilen Bestand an Zielen. Der komplizierteste Login-Ablauf ist kein guter Ausgangspunkt.

Zunächst werden sämtliche Hostnamen des erfolgreichen Pfads erfasst, einschließlich Weiterleitungen und Asset-Hosts. Danach startet eine geschützte Browser Session: Das gewünschte Ergebnis wird geprüft, anschließend wird bewusst ein nicht freigegebener Hostname angefragt und der 403-Nachweis gespeichert. Zum Abschluss erhält ein Teammitglied einen Read-only-Link für Live View und bestätigt, dass Beobachten möglich ist, Interagieren jedoch nicht.

Aus dem Pilotversuch sollten vier Werte festgehalten werden: die Zahl der benötigten Hostnamen, die dafür aufgewendete Pflegezeit, die Anzahl der anfangs irrtümlich blockierten legitimen Anfragen und die durchschnittliche Spitze gleichzeitiger Browser. Diese vier Werte zeigen, ob die Kontrolle für den jeweiligen Workflow sauber umsetzbar ist oder zu einem teuren Versprechen wird.

Noch diese Woche lohnt sich der Schritt, wenn Browseraufträge an Kunden ausgeliefert werden, die erforderlichen Hosts bestimmbar sind und eine Beobachtung ohne Bedienmöglichkeit ein echtes Freigabeproblem löst. Abwarten ist sinnvoll, wenn sich die Abhängigkeiten ständig ändern oder der Auftrag noch über Quick Actions läuft und der Wechsel zu Browser Sessions nicht kalkuliert wurde. Wer weder Browser Sessions betreibt noch Live-Browserarbeit teilt, muss den Montag wegen dieser Veröffentlichung nicht anders planen.

Weitere praxisnahe Einordnungen zu Plattformänderungen gibt es im Newsletter.