Los Workers y Pages de Cloudflare no tienen control de acceso por recurso — y no existe una solución real | Evolving Cyber Blog

Cloudflare Workers y Pages son productos poderosos e impresionantes. Pero mientras trabajaba en la aplicación de controles de acceso con privilegios mínimos para una cuenta de producción que ejecuta múltiples proyectos de Workers y Pages, me encontré con un obstáculo insalvable: no hay manera en Cloudflare de limitar un rol de miembro o un token de API a un solo Worker o a un solo proyecto de Pages. No a través del alcance de dominio. No a través de los permisos del token. No a través de ninguna combinación de configuraciones en el panel de control. Simplemente no existe.

Esta publicación documenta la brecha con precisión, tal como la encontré: lo que intenté, lo que la comunidad está haciendo para solucionarlo temporalmente, por qué esos métodos no resuelven completamente el problema y lo que Cloudflare necesitaría desarrollar para corregirlo. Estoy escribiendo esto como un desarrollador que se encontró con esto en producción, no como un investigador de seguridad que construye un escenario teórico.

Esto no es un caso límite de nicho. Cualquier equipo que ejecute más de un proyecto Worker o Pages —con más de un desarrollador o una sola canalización de CI/CD— se ve afectado por esta brecha.

El Problema: Todo Es A Nivel De Cuenta

En el modelo de permisos de Cloudflare, tanto Workers como Pages son recursos a nivel de cuenta. Cuando otorgas acceso a cualquier rol o token a Workers o Pages, ese acceso se aplica a todos los Workers y a todos los proyectos de Pages en la cuenta; no existe un filtro de recursos a nivel individual de Worker o proyecto.

Roles de Miembro

Cuando agregas a un miembro del equipo y le asignas el rol de "Administrador de Cloudflare Workers", puede leer, escribir y eliminar todos los Workers en tu cuenta. Lo mismo aplica para Pages: un miembro con acceso a Pages tiene acceso a todos los proyectos de Pages, sin forma de restringirlo a un solo proyecto. No hay ningún mecanismo para decir "este desarrollador solo puede acceder a worker-payments" o "este desarrollador solo puede desplegar en el proyecto Pages de marketing". Ambos roles se aplican a toda la cuenta, y esa es la única opción.

Cloudflare tiene una función llamada Roles con Alcance de Dominio, que te permite restringir el acceso de un miembro a zonas específicas. Esto suena relevante, pero no lo es. Los Roles con Alcance de Dominio se aplican exclusivamente a los recursos a nivel de zona: DNS, SSL, reglas de firewall, reglas de página. Workers y Pages son recursos a nivel de cuenta y quedan totalmente fuera del sistema de alcance de dominio. Asignar un rol con alcance de dominio no impone ninguna restricción sobre Workers o Pages. Un miembro con el rol de Administrador de Workers limitado solo a tu zona de producción todavía tiene Administrador de Workers — y acceso a Pages — en toda tu cuenta.

Los roles con alcance de dominio no se aplican a Workers ni a Pages. No ofrecen ninguna solución para este problema — ninguna.

Fichas ### API

Los tokens de API son la forma en que los pipelines de CI/CD se autentican para desplegar Workers a través de Wrangler y Pages a través de la API de Cloudflare o wrangler pages deploy. Cuando creas un token con el permiso "Workers Scripts: Edit", puede leer, escribir y eliminar cualquier Worker en tu cuenta. Cuando creas un token con el permiso "Cloudflare Pages: Edit", puede leer, escribir y eliminar cualquier proyecto de Pages en tu cuenta. Ningún permiso acepta un filtro de recursos a nivel de Worker individual o proyecto.

La propia documentación de Cloudflare sobre despliegues CI/CD reconoce esto directamente, aconsejando a los desarrolladores 'delimitar tu token' y restringirlo a una cuenta específica, pero la mejor granularidad ofrecida es a nivel de cuenta. Puedes restringir un token a una cuenta de entre varias que posees, pero no puedes restringirlo a un Worker o a un proyecto de Pages dentro de esa cuenta.

El blog de permisos de Cloudflare (septiembre de 2023) confirma esto directamente: hasta esa fecha, el alcance de recursos más allá de las zonas es limitado; los tokens R2 pueden asignarse a buckets específicos, pero Workers y Pages no tienen equivalente. Esto se confirma nuevamente en la documentación de Workers Builds, que genera automáticamente un token de despliegue que cubre Workers Scripts (editar), Workers KV Storage (editar), Workers R2 Storage (editar) y Workers Routes (editar) — a nivel de cuenta, sin opción de restringirlo a un solo nombre de script. Los despliegues de Pages a través de CI/CD enfrentan el mismo problema: el permiso Cloudflare Pages: Edit abarca todos los proyectos de Pages en la cuenta.

Los tokens con límite de tiempo no ayudan

Una sugerencia común es usar tokens con tiempo limitado —tokens que expiran después de un período corto— para limitar la exposición. Esto vale la pena hacerlo como una medida general de higiene, pero no aborda el problema del alcance en absoluto. Un token que expira en una hora todavía tiene acceso completo a toda la cuenta para cada Worker y cada proyecto de Pages durante esa hora. La expiración automatiza el tiempo de revocación —no restringe lo que el token puede tocar mientras esté activo.

El principio de mínimo privilegio se trata del alcance, no de la duración. Los tokens con límite de tiempo limitan la ventana de exposición. No restringen a qué proyectos de Workers o Pages puede acceder un token. Estos son problemas diferentes.

Qué Esto Rompe

Estos dos vacíos juntos rompen los dos principios de control de acceso más fundamentales en los sistemas de producción:

Mínimos privilegios: Un token de CI/CD para worker-payments no debería tener permiso permanente para modificar worker-auth, worker-checkout, ni ningún proyecto de Pages. Una canalización de despliegue para tu sitio de marketing no debería poder tocar tu Worker de pagos. Hoy en día, pueden hacerlo, y no hay ningún mecanismo en la plataforma para prevenirlo.
Separación de funciones: Un desarrollador que trabaje en un Worker o proyecto de Pages no debería poder tocar los recursos de otro equipo en producción. Hoy en día, si tienen acceso a Workers o Pages, pueden hacerlo.

El radio de alcance de un token comprometido o de una cuenta de desarrollador víctima de phishing es toda la superficie de Workers y Pages de su cuenta. En una cuenta de producción con múltiples equipos y proyectos, eso representa una exposición significativa.

Lo Que Los Desarrolladores Realmente Están Haciendo: Las Soluciones Alternativas

Debido a que la plataforma no proporciona controles de acceso por trabajador o por proyecto de páginas, los equipos han adoptado un conjunto de patrones compensatorios. Esto es lo que realmente se está utilizando en la práctica, y un relato honesto de las limitaciones de cada uno.

El Patrón de Cuenta Separada: La Solución Alternativa Más Común

La solución alternativa más recomendada en la comunidad de Cloudflare es aislar los proyectos de Workers y Pages en cuentas de Cloudflare separadas: una cuenta por proyecto o equipo. Cada cuenta tiene sus propios miembros y tokens, y como cada cuenta es un límite rígido, el acceso está naturalmente aislado.

Un hilo de la comunidad de Cloudflare de abril de 2025 — preguntando directamente "¿Pueden los miembros acceder solo a mis Workers en lugar de a toda la cuenta del dominio?" — ilustra lo común que es esta pregunta. La respuesta de la comunidad, consistente en varios hilos que datan de hace años, es la misma: necesitas cuentas separadas. Otro hilo de abril de 2025 preguntaba sobre cómo aislar la gestión de diferentes aplicaciones Worker, D1 y Pages entre equipos en una empresa pequeña — la pregunta menciona Pages explícitamente — y, de nuevo, la respuesta señalaba la separación de cuentas como la única opción real.

Este patrón sí logra el objetivo de aislamiento. Pero llamarlo una solución temporal minimiza lo doloroso que es operativamente en realidad:

Proliferación de cuentas y fragmentación de facturación. Cada cuenta es una entidad de facturación separada, un panel separado y un conjunto separado de credenciales que hay que asegurar y rotar. Gestionar miembros, SSO y registros de auditoría en N cuentas escala de manera deficiente.
Los recursos no pueden cruzar los límites de la cuenta. Los Workers que necesitan compartir namespaces de KV, bases de datos D1, buckets R2 u Objetos Duraderos no pueden hacerlo entre cuentas. Los proyectos de Pages que usan Workers como funciones de backend enfrentan la misma limitación: las vinculaciones de servicios están limitadas a la cuenta.
No hay manera de transferir un Worker o un proyecto de Pages entre cuentas. Si desarrollas en una cuenta aislada y deseas moverlo a tu cuenta principal de producción, debes recrear manualmente el script o proyecto, todas las vinculaciones, variables de entorno, secretos y rutas desde cero. No existe una API de transferencia ni una ruta de migración para Workers o Pages.
La observabilidad está fragmentada. Los registros, análisis y métricas son por cuenta. Pierdes visibilidad unificada de tu flota de Workers y Pages y necesitas herramientas externas para agregarla.

Crear cuentas separadas para aislar proyectos de Workers y Pages es un control compensatorio, no una arquitectura de seguridad diseñada. Estás buscando una solución a la falta de un límite de autorización, no construyendo uno.

Fichas de corta duración con rotación agresiva

Algunos equipos mitigan el riesgo generando un token API nuevo para cada ejecución de despliegue y revocándolo inmediatamente después. Esto se aplica igualmente a los despliegues de Workers a través de Wrangler y a los despliegues de Pages a través de wrangler pages deploy o la API de Cloudflare. Este es un paso legítimo de defensa en profundidad y vale la pena hacerlo, pero solo limita la duración de la exposición, no su alcance. El token todavía tiene acceso completo a todas las cuentas de proyectos de Workers y Pages mientras exista.

Implementar esto correctamente también requiere una infraestructura CI/CD que admita la creación y revocación dinámica de tokens a través de la API de Cloudflare, la cual la mayoría de las configuraciones estándar de pipelines no soportan de manera predeterminada.

# 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"
}

Bloqueando el acceso a la API por usuario

El sistema de permisos de Cloudflare permite a los Super Administradores restringir qué miembros de la cuenta tienen permitido generar tokens de API en absoluto. Esto puede centralizar la creación de tokens en una única cuenta de servicio, reduciendo el número de personas que pueden crear tokens con permisos amplios tanto sobre Workers como sobre Pages.

Este es un control administrativo útil, pero no resuelve el problema del alcance. Los tokens creados por la cuenta de servicio aún tienen acceso a Workers y Pages a nivel de cuenta. Reduce el número de superficies a través de las cuales un token con exceso de alcance puede ser creado o mal utilizado, pero los tokens que se crean todavía tienen exceso de alcance por diseño.

Lo que Cloudflare necesita construir

La solución no es arquitectónicamente compleja de describir. La publicación del blog de Cloudflare de 2022 que introducía los Roles con Ámbito de Dominio describía su sistema de permisos Bach como compatible con el alcance de recursos para "cuentas, zonas, entornos de trabajadores o registros DNS." Los entornos de trabajadores se nombran explícitamente como un tipo de recurso en ese sistema subyacente, y los proyectos de Pages deberían tratarse de la misma manera.

La brecha es que esta capacidad no se ha expuesto para Workers o Páginas en el producto. Lo que necesita suceder:

Tokens de API: El grupo de permisos de Scripts de Workers necesita aceptar un filtro de recursos de nombres individuales de scripts de Worker. El grupo de permisos de Cloudflare Pages necesita aceptar un filtro de recursos de nombres individuales de proyectos de Pages. Un token limitado a Workers Scripts: Edit en el recurso worker-payments no debería poder acceder a worker-auth. Un token limitado a Cloudflare Pages: Edit en el proyecto marketing-site no debería poder acceder a payments-portal.
Roles de miembros: Los roles de Administrador de Workers y Pages (o las nuevas variantes por recurso) deberían poder aplicarse a Workers con nombre y proyectos de Pages con nombre, no solo a zonas como funcionan hoy los Roles con Alcance de Dominio, y tampoco de manera que otorgue acceso a toda la cuenta.
R2 es la prueba de concepto: Cloudflare ya admite el alcance a nivel de bucket para tokens de R2. Aplicar el mismo patrón a nombres de scripts de Worker y nombres de proyectos de Pages resolvería esto. La capacidad existe en el modelo de permisos; necesita aplicarse a Workers y Pages.

Esto permitiría que un token CI/CD fuera incapaz, por la imposición de la plataforma, de interactuar con cualquier proyecto de Worker o Pages que no sea aquel para el que fue emitido. Una cuenta de desarrollador comprometida tendría su radio de acción limitado a los recursos asignados. La separación de funciones entre los equipos de producto sería impuesta por la plataforma, no por la política y la confianza organizacional.

Qué deben hacer los equipos ahora mismo

Mientras existe esta brecha, aquí se explica cómo acercarse lo más posible al mínimo privilegio que la plataforma permite actualmente. Estos son controles compensatorios, no soluciones, y deben entenderse como tales.

Aísla tus proyectos más críticos de Workers y Pages en una cuenta dedicada. Si tienes un número reducido de recursos de alto valor —Workers de procesamiento de pagos, aplicaciones Pages orientadas al cliente, servicios de autenticación— y puedes tolerar la sobrecarga operativa, ponerlos en su propia cuenta proporciona un aislamiento real. Acepta que compartir recursos y la capacidad de observación serán más difíciles como compensación.
Genera tokens de corta duración por implementación y revócalos inmediatamente. Esto se aplica tanto a las canalizaciones de Workers como de Pages. Limita la ventana de exposición incluso si no puedes limitar el alcance.
Restringe la creación de tokens de API a una única cuenta de servicio. Usa el control de acceso a la API por usuario de Cloudflare para evitar que los miembros del equipo creen sus propios tokens amplios de manera independiente.
Monitorea el registro de auditoría. Usa la API del Registro de Auditoría de Cloudflare para rastrear cargas de scripts de Workers, eventos de implementación de Pages y cualquier cambio en cualquiera de ellos. Genera alertas sobre actores inesperados o nombres de recursos inesperados que sean modificados.
Plantea el tema formalmente con Cloudflare. Si tienes un plan Enterprise, solicita RBAC por recurso tanto para Workers como para Pages con tu CSM como una solicitud de producto nombrada. Publica en el foro de la Community. Cuantos más equipos documenten explícitamente esta brecha, mayor será la presión para cerrarla.

# 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.

Cierre

Cloudflare es una plataforma que usamos y recomendamos. Esta publicación no es una condena; es un relato preciso y documentado de una brecha específica que importa para la seguridad en producción tanto en Workers como en Pages. Se informa que la infraestructura para solucionarlo ya existe en Bach. La solicitud es directa: exponer la delimitación por recurso para tokens y roles en Workers y Pages, exactamente como ya existe para los buckets de R2.

En Evolving Cyber, creemos que una buena seguridad es una decisión de diseño, no una adaptación posterior. Ese principio se aplica a las plataformas sobre las que construimos, no solo al software que desarrollamos. Cuando una plataforma hace que el principio de menor privilegio sea operativamente imposible, o alcanzable solo a través de la proliferación de cuentas y compensaciones manuales, desplaza la carga de la seguridad completamente a los equipos que la utilizan. Eso no es un buen diseño.

La solicitud: asignar el alcance de los tokens de API y los roles de los miembros a nombres individuales de scripts de Workers y nombres de proyectos de Pages. R2 ya hace esto para los buckets. Workers y Pages necesitan lo mismo.