DeerFlow
Seguridad de DeerFlow: prioridad bearer, CSRF y autoridad de ejecución
Lee juntas la autenticación y la protección CSRF, y revisa el proxy y los permisos que siguen importando después de iniciar sesión.
Qué aprenderás
- La autenticación selecciona una ruta de credenciales
- Comprueba CSRF junto con la prioridad bearer
- Concede menos autoridad de ejecución que de cuenta
Antes de empezar
- Conceptos básicos de Python, HTTP y contenedores
- Una tarea propia con criterios de aceptación
Explica el límite de implementación y aplica la lista o el ejercicio aislado del capítulo.
Conclusiones clave
- Un bearer inválido no debe recurrir a cookies.
- CSRF depende también de autenticación y proxy.
- Sesión, permisos e aislamiento son fronteras separadas.
La autenticación selecciona una ruta de credenciales
Con autenticación habilitada, una cabecera Authorization selecciona la ruta PAT; un token inválido recibe 401 y no recurre a la cookie de sesión. El middleware también limita rutas PAT e intersecta sus ámbitos con los permisos efectivos del usuario. El token interno confiable tiene otra ruta. Estas decisiones de identidad no reemplazan la autorización por recurso en los controladores.
Algunas rutas son públicas, como salud y ciertos extremos de autenticación inicial; los controladores de webhooks tienen su propia responsabilidad de verificación. El middleware emplea un auxiliar de rutas alineado con el router. El manifiesto limita incluso una dependencia Starlette utilizada por ese auxiliar, mostrando que el comportamiento de enrutamiento del framework puede afectar a la seguridad.
Comprueba CSRF junto con la prioridad bearer
Las peticiones protegidas que modifican estado mediante cookies comparan una cookie legible con X-CSRF-Token mediante comparación de tiempo constante. Una cabecera Authorization presente evita esa doble comprobación, pero depende de que la autenticación rechace credenciales bearer inválidas. Leer únicamente la exención oculta la suposición compartida entre ambas capas.
Las rutas iniciales de autenticación comprueban Origin cuando está presente y permiten su ausencia para clientes no navegador. La normalización rechaza credenciales, rutas, consultas y fragmentos y normaliza puertos por defecto. El origen de la petición acepta cabeceras reenviadas: el proxy debe eliminar o sobrescribir entradas no confiables. Una lista CORS exacta no corrige por sí sola una frontera de proxy incorrecta.
Concede menos autoridad de ejecución que de cuenta
El proveedor local declara que no aísla el sistema de archivos del host cuando se habilita su shell. La composición base evita el socket Docker y los directorios personales de credenciales CLI; montarlos amplía la autoridad disponible para una herramienta comprometida o una tarea maliciosa. Revisa esas capacidades independientemente de que el usuario haya iniciado sesión.
Utiliza muestras desechables para comprobar acceso no autorizado, credenciales caducadas, CSRF en escrituras, propiedad de archivos y parada. Redacta tokens, define retención y prueba restauración. Inspeccionamos estas ramas, pero no iniciamos un servidor de autenticación ni realizamos una prueba de penetración. Un límite de bucle frena futuras llamadas; no deshace efectos externos ya ocurridos.
Pasos de implementación
- 1
Mantén autenticación y acceso detrás del proxy TLS previsto.
- 2
Limpia cabeceras reenviadas y utiliza orígenes exactos.
- 3
Evita montar credenciales o el socket Docker sin necesidad explícita.
- 4
Prueba identidad, propiedad y recuperación con muestras no sensibles.
Ejemplo para copiar
{"authEnabled":true,"invalidBearerCookieFallback":false,"cookieWritesRequireCsrf":true,"trustedProxyRequired":true,"hostBashAllowed":false,"securityIntegrationTestExecuted":false}Preguntas frecuentes
¿Una cabecera Authorization arbitraria evita autenticarse?
No. Con autenticación habilitada, el middleware correspondiente rechaza bearer inválidos y no usa la cookie como alternativa.
¿Detener el agente revierte efectos de herramientas?
No. La terminación puede impedir llamadas posteriores; los efectos externos necesitan idempotencia, aprobación y recuperación propias.
Fuentes
- README.mdFuente verificada 2026-09-08
- LICENSEFuente verificada 2026-09-08
- backend/README.mdFuente verificada 2026-09-08
- backend/pyproject.tomlFuente verificada 2026-09-08
- backend/docs/middleware-execution-flow.mdFuente verificada 2026-09-08
- backend/packages/harness/deerflow/agents/lead_agent/agent.pyFuente verificada 2026-09-08
- backend/packages/harness/deerflow/agents/middlewares/loop_detection_middleware.pyFuente verificada 2026-09-08
- backend/packages/harness/deerflow/agents/middlewares/_bounded_dict.pyFuente verificada 2026-09-08
- backend/packages/harness/deerflow/config/loop_detection_config.pyFuente verificada 2026-09-08
- backend/packages/harness/deerflow/sandbox/local/local_sandbox_provider.pyFuente verificada 2026-09-08
- backend/app/gateway/auth_middleware.pyFuente verificada 2026-09-08
- backend/app/gateway/csrf_middleware.pyFuente verificada 2026-09-08
- docker/docker-compose.yamlFuente verificada 2026-09-08