Cloudflare Workers und Pages haben keine pro-Ressource Zugriffssteuerung – und es gibt keine echte Umgehung. | Evolving Cyber Blog

Cloudflare Workers und Pages sind leistungsstarke, wirklich beeindruckende Produkte. Aber während ich daran arbeitete, Zugriffskontrollen nach dem Prinzip der minimalen Rechte für ein Produktionskonto durchzusetzen, das mehrere Workers- und Pages-Projekte betreibt, stieß ich auf eine harte Wand: Es gibt keine Möglichkeit in Cloudflare, eine Mitgliederrolle oder ein API-Token auf einen einzelnen Worker oder ein einzelnes Pages-Projekt zu beschränken. Weder durch Domain-Scoping. Weder durch Token-Berechtigungen. Weder durch irgendeine Kombination von Einstellungen im Dashboard. Es existiert einfach nicht.

Dieser Beitrag dokumentiert die Lücke genau so, wie ich ihr begegnet bin — was ich versucht habe, was die Community unternimmt, um sie zu umgehen, warum diese Umgehungen das Problem nicht vollständig lösen und was Cloudflare entwickeln müsste, um es zu beheben. Ich schreibe dies als Entwickler, der dies in der Produktion erlebt hat, nicht als Sicherheitsforscher, der ein theoretisches Szenario konstruiert.

Dies ist kein spezieller Einzelfall. Jedes Team, das mehr als ein Worker- oder Pages-Projekt betreibt – mit mehr als einem Entwickler oder einer CI/CD-Pipeline – ist von dieser Lücke betroffen.

Das Problem: Alles gilt kontenübergreifend

Im Berechtigungsmodell von Cloudflare sind sowohl Workers als auch Pages Ressourcen auf Kontoebene. Wenn Sie einer Rolle oder einem Token Zugriff auf Workers oder Pages gewähren, gilt dieser Zugriff für jeden Worker und jedes Pages-Projekt im Konto — es gibt keinen Ressourcenfilter auf Ebene einzelner Worker oder Projekte.

Mitgliederrollen

Wenn Sie ein Teammitglied hinzufügen und ihm die Rolle "Cloudflare Workers Admin" zuweisen, kann es jeden Worker in Ihrem Konto lesen, schreiben und löschen. Dasselbe gilt für Pages – ein Mitglied mit Zugriff auf Pages hat Zugriff auf alle Pages-Projekte, ohne dass es möglich ist, den Zugriff auf ein einzelnes Projekt zu beschränken. Es gibt keinen Mechanismus, um zu sagen: "Dieser Entwickler darf nur auf worker-payments zugreifen" oder "Dieser Entwickler darf nur auf das Marketing-Pages-Projekt deployen." Beide Rollen gelten kontenweit, und das ist die einzige Option.

Cloudflare hat eine Funktion namens Domain Scoped Roles, die es Ihnen erlaubt, den Zugriff eines Mitglieds auf bestimmte Zonen zu beschränken. Das klingt relevant – ist es aber nicht. Domain Scoped Roles gelten ausschließlich für Ressourcen auf Zonenebene: DNS, SSL, Firewall-Regeln, Seitenregeln. Workers und Pages sind Ressourcen auf Kontoebene und fallen vollständig außerhalb des Domain-Scoping-Systems. Das Zuweisen einer domain-gescoped Rolle schränkt den Zugriff auf Workers oder Pages überhaupt nicht ein. Ein Mitglied mit Workers-Admin-Rechten, das nur auf Ihre Produktionszone beschränkt ist, hat immer noch Workers-Admin – und Pages-Zugriff – auf Ihr gesamtes Konto.

Domain-spezifische Rollen gelten nicht für Worker oder Pages. Sie bieten keine Entlastung für dieses Problem — keine.

API-Token

API-Token sind der Weg, wie CI/CD-Pipelines sich authentifizieren, um Worker über Wrangler und Pages über die Cloudflare-API oder wrangler pages deploy bereitzustellen. Wenn Sie ein Token mit der Berechtigung „Workers Scripts: Bearbeiten“ erstellen, kann es jeden Worker in Ihrem Konto lesen, schreiben und löschen. Wenn Sie ein Token mit der Berechtigung „Cloudflare Pages: Bearbeiten“ erstellen, kann es jedes Pages-Projekt in Ihrem Konto lesen, schreiben und löschen. Keine der Berechtigungen akzeptiert einen Ressourcenfilter auf der Ebene einzelner Worker oder Projekte.

Die eigene Dokumentation von Cloudflare zu CI/CD-Bereitstellungen erkennt dies direkt an und empfiehlt Entwicklern, "ihr Token einzugrenzen" und auf ein bestimmtes Konto zu beschränken – aber die beste angebotene Granularität ist auf Kontoebene. Sie können ein Token auf ein Konto von mehreren Konten, die Sie besitzen, beschränken, aber nicht auf einen Worker oder ein Pages-Projekt innerhalb dieses Kontos beschränken.

Cloudflares Berechtigungs-Blog (September 2023) bestätigt dies direkt: Stand dieses Schreibens ist die Ressourcenzuordnung über Zonen hinaus eingeschränkt – R2-Token können auf bestimmte Buckets beschränkt werden, aber Workers und Pages haben kein Äquivalent. Dies wird erneut in der Workers Builds-Dokumentation bestätigt, die automatisch ein Bereitstellungstoken für Workers Scripts (Bearbeiten), Workers KV Storage (Bearbeiten), Workers R2 Storage (Bearbeiten) und Workers Routes (Bearbeiten) erstellt – kontoweit, ohne die Möglichkeit, auf einen einzelnen Skriptnamen einzugrenzen. Pages-Bereitstellungen über CI/CD haben dasselbe Problem: Die Berechtigung Cloudflare Pages: Bearbeiten gilt für jedes Pages-Projekt im Konto.

Zeitlich begrenzte Token helfen nicht

Ein häufiger Vorschlag ist die Verwendung zeitlich begrenzter Tokens — Tokens, die nach einem kurzen Zeitraum ablaufen — um das Risiko zu begrenzen. Dies ist als allgemeine Hygienemaßnahme sinnvoll, löst jedoch überhaupt nicht das Problem des Umfangs. Ein Token, das in einer Stunde abläuft, hat während dieser Stunde weiterhin vollen kontenweiten Zugriff auf jeden Worker und jedes Pages-Projekt. Das Ablaufen automatisiert den Zeitpunkt der Widerrufung — es beschränkt nicht, was das Token während seiner Aktivität berühren kann.

Prinzip der geringsten Berechtigung bezieht sich auf den Umfang, nicht auf die Dauer. Zeitlich begrenzte Token begrenzen das Risiko-Fenster. Sie schränken nicht ein, auf welche Worker- oder Pages-Projekte ein Token zugreifen kann. Dies sind unterschiedliche Probleme.

Was Das Bricht

Diese beiden Lücken zusammen verletzen die beiden grundlegendsten Prinzipien der Zugriffskontrolle in Produktionssystemen:

Minimalberechtigung: Ein CI/CD-Token für Worker-Zahlungen sollte keine dauerhaften Berechtigungen besitzen, um Worker-Auth, Worker-Checkout oder irgendein Pages-Projekt zu ändern. Eine Deployment-Pipeline für Ihre Marketing-Website sollte Ihren Zahlungs-Worker nicht berühren können. Heute können sie es — und es gibt keinen Plattformmechanismus, dies zu verhindern.
Trennung der Aufgaben: Ein Entwickler, der an einem Worker- oder Pages-Projekt arbeitet, sollte nicht in der Lage sein, auf die Ressourcen eines anderen Teams in der Produktion zuzugreifen. Heute können sie es, sofern sie überhaupt Zugriff auf Workers oder Pages haben.

Die Explosionsreichweite eines kompromittierten Tokens oder eines gehackten Entwicklerkontos umfasst die gesamte Workers- und Pages-Oberfläche Ihres Kontos. In einem Produktionskonto mit mehreren Teams und Projekten stellt dies ein erhebliches Risiko dar.

Was Entwickler tatsächlich tun: Die Umgehungslösungen

Da die Plattform keine Zugriffssteuerungen pro Worker oder pro Pages-Projekt bereitstellt, haben Teams eine Reihe von ausgleichenden Mustern entwickelt. Hier ist, was tatsächlich in der Praxis verwendet wird — und eine ehrliche Darstellung der Einschränkungen jedes einzelnen.

Das Separate-Account-Muster — Die gebräuchlichste Umgehungslösung

Die am häufigsten empfohlene Lösung in der Cloudflare-Community besteht darin, Workers- und Pages-Projekte in separate Cloudflare-Konten zu isolieren – ein Konto pro Projekt oder Team. Jedes Konto erhält eigene Mitglieder und Tokens, und da jedes Konto eine harte Grenze bildet, ist der Zugriff natürlich isoliert.

Ein Cloudflare-Community-Thread aus dem April 2025 — der direkt fragte: „Können Mitglieder nur Zugriff auf meine Workers bekommen, anstatt auf das gesamte Domain-Konto?“ — zeigt, wie häufig diese Frage ist. Die Antwort aus der Community, die über mehrere Threads hinweg über Jahre konsistent ist, lautet dieselbe: Man braucht separate Konten. Ein weiterer Thread aus dem April 2025 fragte danach, wie die Verwaltung verschiedener Worker-, D1- und Pages-Apps zwischen Teams in einem kleinen Unternehmen isoliert werden kann — der Thread nennt Pages explizit — und auch hier deutete die Antwort darauf hin, dass Kontentrennung die einzige wirkliche Option ist.

Dieses Muster erreicht tatsächlich das Isolationsziel. Aber es als Übergangslösung zu bezeichnen, unterschätzt, wie betrieblich schmerzhaft es tatsächlich ist:

Kontoausbreitung und Abrechnungsfragmentierung. Jedes Konto ist eine eigene Abrechnungseinheit, ein separates Dashboard, ein eigenes Set an Zugangsdaten, die gesichert und regelmäßig geändert werden müssen. Die Verwaltung von Mitgliedern, SSO und Prüfprotokollen über N Konten skaliert schlecht.
Ressourcen können Kontengrenzen nicht überschreiten. Worker, die KV-Namespaces, D1-Datenbanken, R2-Buckets oder Durable Objects teilen müssen, können dies nicht über Konten hinweg tun. Pages-Projekte, die Worker als Backend-Funktionen verwenden, stehen vor derselben Einschränkung — Service-Bindungen sind kontenabhängig.
Es gibt keine Möglichkeit, einen Worker oder ein Pages-Projekt zwischen Konten zu übertragen. Wenn Sie in einem isolierten Konto entwickeln und es in Ihrem Hauptproduktionskonto einfügen möchten, müssen Sie das Skript oder Projekt, alle Bindungen, Umgebungsvariablen, Geheimnisse und Routen manuell von Grund auf neu erstellen. Es gibt keine Transfer-API und keinen Migrationspfad für Worker oder Pages.
Beobachtbarkeit fragmentiert. Logs, Analysen und Metriken sind kontenabhängig. Sie verlieren die einheitliche Übersicht über Ihre Worker- und Pages-Flotte und benötigen externe Tools, um diese zusammenzuführen.

Das Erstellen separater Konten, um Workers- und Pages-Projekte zu isolieren, ist eine ausgleichende Kontrolle – keine gestaltete Sicherheitsarchitektur. Sie umgehen eine fehlende Autorisierungsgrenze, anstatt eine zu erstellen.

Kurzlebige Token mit aggressiver Rotation

Einige Teams mindern das Risiko, indem sie für jeden Bereitstellungsdurchlauf ein neues API-Token erzeugen und es unmittelbar danach widerrufen. Dies gilt gleichermaßen für Workers-Bereitstellungen über Wrangler und Pages-Bereitstellungen über wrangler pages deploy oder die Cloudflare-API. Dies ist eine legitime Maßnahme zur Verteidigung in der Tiefe und es lohnt sich, sie durchzuführen – sie begrenzt jedoch nur die Expositionsdauer, nicht den Umfang. Das Token hat weiterhin vollen kontoweiten Zugriff auf alle Workers- und Pages-Projekte, solange es existiert.

Die ordnungsgemäße Implementierung erfordert auch eine CI/CD-Infrastruktur, die die dynamische Erstellung und Widerrufung von Token über die Cloudflare-API unterstützt, was die meisten Standard-Pipeline-Konfigurationen nicht von Haus aus unterstützen.

# Illustrative: short-lived token via Cloudflare API
# Even with expiry set, Workers Scripts: Edit still covers ALL Workers.
# Cloudflare Pages: Edit still covers ALL Pages projects.
# There is no script_name or project_name resource filter in the permissions API.

POST /client/v4/user/tokens
{
  "name": "ci-deploy-worker-payments-2026-03-11",
  "policies": [{
    "effect": "allow",
    "resources": { "com.cloudflare.api.account.ACCOUNT_ID": "*" },
    "permission_groups": [{ "id": "<workers-scripts-edit-group-id>" }]
    // ^ No per-Worker or per-Pages-project resource filter exists. Account-wide only.
  }],
  "not_before": "2026-03-11T10:00:00Z",
  "expires_on":  "2026-03-11T11:00:00Z"
}

APIs-Zugriff pro Benutzer sperren

Das Berechtigungssystem von Cloudflare ermöglicht es Superadministratoren, einzuschränken, welche Kontomitglieder überhaupt API-Tokens erstellen dürfen. Dies kann die Token-Erstellung in ein einziges Servicekonto zentralisieren und die Anzahl der Personen reduzieren, die Tokens mit umfassenden Berechtigungen sowohl für Workers als auch für Pages erstellen können.

Dies ist eine nützliche administrative Kontrolle — aber sie löst das Problem des Umfangs nicht. Tokens, die vom Servicekonto erstellt werden, haben immer noch accountweite Zugriffe auf Workers und Pages. Es verringert die Anzahl der Bereiche, durch die ein überumfangreiches Token erstellt oder missbraucht werden kann, aber die Tokens, die erstellt werden, sind von vornherein immer noch überumfangreich.

Was Cloudflare zum Aufbauen benötigt

Die Lösung ist architektonisch nicht komplex zu beschreiben. Der Blogbeitrag von Cloudflare aus dem Jahr 2022, in dem Domain Scoped Roles vorgestellt wurden, beschrieb ihr Bach-Berechtigungssystem als Unterstützung für die Ressourcenabgrenzung für „Konten, Zonen, Arbeitsumgebungen oder DNS-Einträge“. Arbeitsumgebungen werden in diesem zugrunde liegenden System ausdrücklich als Ressourcentyp genannt – und Pages-Projekte sollten auf dieselbe Weise behandelt werden.

Die Lücke besteht darin, dass diese Fähigkeit für Workers oder Pages im Produkt nicht zugänglich gemacht wurde. Was geschehen muss:

API-Tokens: Die Berechtigungsgruppe "Worker Scripts" muss einen Ressourcenfilter für einzelne Worker-Skriptnamen akzeptieren. Die Berechtigungsgruppe "Cloudflare Pages" muss einen Ressourcenfilter für einzelne Pages-Projektnamen akzeptieren. Ein Token, das auf Workers Scripts: Edit für die Ressource worker-payments beschränkt ist, sollte nicht in der Lage sein, worker-auth zu berühren. Ein Token, das auf Cloudflare Pages: Edit für das Projekt marketing-site beschränkt ist, sollte nicht in der Lage sein, payments-portal zu berühren.
Mitgliederrollen: Die Rollen Workers Admin und Pages (oder neue Varianten pro Ressource) sollten auf benannte Worker und benannte Pages-Projekte beschränkt werden können — nicht nur auf Zonen, wie es die Domain Scoped Roles heute tun, und nicht auf eine Weise, die weiterhin kontenweite Zugriffe gewährt.
R2 ist der Proof of Concept: Cloudflare unterstützt bereits die Bucket-Ebene-Beschränkung für R2-Tokens. Dasselbe Muster angewendet auf Worker-Skriptnamen und Pages-Projektnamen würde dieses Problem lösen. Die Möglichkeit existiert im Berechtigungsmodell — sie muss nur auf Workers und Pages angewendet werden.

Dies würde es einem CI/CD-Token ermöglichen, durch die Durchsetzung der Plattform unfähig zu sein, auf ein anderes Worker- oder Pages-Projekt als das, für das es ausgegeben wurde, zuzugreifen. Ein kompromittiertes Entwicklerkonto wäre auf die ihm zugewiesenen Ressourcen beschränkt. Die Trennung der Aufgaben zwischen den Produktteams würde von der Plattform durchgesetzt werden – nicht durch organisatorische Richtlinien und Vertrauen.

Was Teams jetzt tun sollten

Während diese Lücke besteht, ist hier, wie man so nah wie möglich an das Prinzip der minimalen Rechte kommt, das die Plattform derzeit erlaubt. Dies sind kompensierende Kontrollen – keine Lösungen – und sollten als solche verstanden werden.

Isolieren Sie Ihre kritischsten Workers- und Pages-Projekte in einem eigenen Konto. Wenn Sie nur eine kleine Anzahl von hochpriorisierten Ressourcen haben — Zahlungsabwicklungs-Workers, kundenorientierte Pages-Apps, Authentifizierungsdienste — und die betriebliche Belastung tolerieren können, bietet das Platzieren in einem eigenen Konto echte Isolation. Akzeptieren Sie, dass Ressourcenteilung und Überwachbarkeit als Kompromiss schwieriger werden.
Erstellen Sie kurzlebige Tokens pro Deployment und widerrufen Sie sie sofort. Dies gilt sowohl für Workers- als auch für Pages-Pipelines. Begrenzen Sie das Expositionsfenster, selbst wenn Sie den Umfang nicht begrenzen können.
Beschränken Sie die Erstellung von API-Tokens auf ein einzelnes Servicekonto. Verwenden Sie die API-Zugriffskontrolle von Cloudflare pro Benutzer, um zu verhindern, dass Teammitglieder eigene umfassende Tokens unabhängig erstellen.
Überwachen Sie das Audit-Log. Verwenden Sie die Cloudflare Audit Log API, um Worker-Skript-Uploads, Pages-Deployment-Ereignisse und Änderungen an beiden nachzuverfolgen. Alarmieren Sie bei unerwarteten Akteuren oder unerwartet geänderten Ressourcennamen.
Bringen Sie es offiziell bei Cloudflare zur Sprache. Wenn Sie einen Enterprise-Plan haben, erhöhen Sie RBAC pro Ressource sowohl für Workers als auch für Pages mit Ihrem CSM als benannte Produktanfrage. Veröffentlichen Sie es im Community-Forum. Je mehr Teams diese Lücke ausdrücklich dokumentieren, desto größer ist der Druck, sie zu schließen.

# Audit log query: monitor for Worker and Pages changes
GET /client/v4/accounts/{account_id}/audit_logs
  ?action.type=Script+Upload
  &since=2026-01-01T00:00:00Z
  Authorization: Bearer {your_token}

# Run a separate query for Pages deployment events:
GET /client/v4/accounts/{account_id}/audit_logs
  ?action.type=Deployment
  &since=2026-01-01T00:00:00Z
  Authorization: Bearer {your_token}

# Review both for unexpected actors or unexpected resource names.

Schließen

Cloudflare ist eine Plattform, die wir nutzen und empfehlen. Dieser Beitrag ist keine Verurteilung – es ist ein genauer, dokumentierter Bericht über eine spezifische Lücke, die für die Produktionssicherheit sowohl bei Workers als auch bei Pages von Bedeutung ist. Die Infrastruktur zur Behebung soll Berichten zufolge bereits in Bach vorhanden sein. Die Forderung ist einfach: eine pro-Ressource definierte Begrenzung für Tokens und Rollen bei Workers und Pages bereitzustellen, genau so, wie sie bereits für R2-Buckets existiert.

An Evolving Cyber, wir sind der Meinung, dass gute Sicherheit eine Designentscheidung ist, kein nachträglicher Einbau. Dieses Prinzip gilt für die Plattformen, auf denen wir aufbauen, nicht nur für die Software, die wir entwickeln. Wenn eine Plattform das Prinzip der minimalen Berechtigung operativ unmöglich macht – oder nur durch Kontenaufblähung und manuelle Kompensation erreichbar ist – verlagert sie die Sicherheitslast vollständig auf die Teams, die sie nutzen. Das ist kein gutes Design.

Die Anfrage: API-Token und Mitgliederrollen auf einzelne Worker-Skriptnamen und Pages-Projektnamen einschränken. R2 macht dies bereits für Buckets. Workers und Pages benötigen dasselbe.