Ayer, Railway publicó uno de los informes de incidentes más incómodos que he leído en mucho tiempo. Entre las 10:42 y las 11:34 UTC del 30 de marzo, una actualización de configuración en su CDN activó accidentalmente el caché para aproximadamente el 0,05% de los dominios que habían optado explícitamente por no usar la función de CDN de Railway. Durante 52 minutos, las respuestas HTTP GET — incluyendo las autenticadas — fueron almacenadas en el edge y potencialmente servidas a usuarios distintos al solicitante original. Algunos usuarios vieron páginas destinadas a otras personas. Railway purgó el caché globalmente y publicó un postmortem completo el mismo día.
La causa raíz fue técnicamente específica: un ingeniero de Railway activó “Surrogate Keys” en su proveedor de CDN para habilitar la invalidación de caché por dominio. Esa función, sin que nadie lo supiera, pasó por alto completamente el comportamiento de si CDN está desactivado, pasá al origen. Los headers Set-Cookie no fueron cacheados — pero los cuerpos de respuesta sí. Y el cuerpo es donde está el daño.
Esa distinción merece su propio párrafo.
La Trampa de la Cookie No Es la Única Trampa
Existe un modelo mental muy extendido entre los desarrolladores que dice: “si no estoy cacheando cookies, mis sesiones están seguras.” El incidente de Railway rompe ese modelo de forma limpia. Tu cookie de sesión puede estar perfectamente aislada, pero la respuesta HTTP autenticada — la que contiene el nombre de tu usuario, su estado de facturación, identificadores de workspace, tokens CSRF incrustados en formularios, o el JSON que inicializa el frontend — ese cuerpo de respuesta igual puede ser cacheado y servido a la persona equivocada. Podés proteger la cookie y aun así filtrar la página.
La protección estándar son headers Cache-Control explícitos en cualquier respuesta que contenga contenido específico del usuario: Cache-Control: no-store, no-cache, private. Si tu aplicación no emite estos headers en las rutas autenticadas, estás confiando implícitamente en el comportamiento por defecto de tu proveedor de infraestructura — y ese comportamiento por defecto puede cambiar, mal configurarse, o fallar exactamente de esta manera.
Esto no es un escenario hipotético. Acaba de pasar.
La Capa de Conveniencia de PaaS Tiene Su Propia Superficie de Ataque
Quiero ser preciso acá: esto no es una condena a Railway. Publicaron un postmortem transparente, notificaron a los usuarios afectados, purgaron el caché con rapidez, y delinearon medidas preventivas concretas — tests adicionales de comportamiento de caché antes de cambios en producción, y rollouts de CDN escalonados en horas en lugar de minutos. Esa es la postura correcta ante un incidente.
El punto más amplio es arquitectónico. Las plataformas PaaS abstraen una complejidad enorme: DNS, TLS, routing, entrega en el edge, mitigación de DDoS. Esa abstracción tiene valor genuino. Pero también significa que un cambio de configuración dentro de una capa del proveedor que no controlás — una que quizás ni sabías que existía — puede alterar las propiedades de seguridad de tu aplicación sin que tu aplicación cambie en absoluto.
Railway tenía un guard (CDN desactivado → pasar al origen). Un cambio de ingeniería legítimo lo eludió. Las aplicaciones desplegadas en esos dominios afectados no tuvieron visibilidad sobre esto. Ningún código cambió del lado de la aplicación. El comportamiento cambió en la capa de infraestructura.
Qué Significa Esto para Tu Stack
Tres lecciones prácticas de este incidente:
1. Establecé headers de caché explícitos en cada ruta autenticada. No dependas de los defaults de la plataforma. Cache-Control: no-store en cualquier respuesta que contenga contenido con scope de sesión no es opcional — es el piso mínimo. Si tu framework o middleware no lo setea para las respuestas autenticadas, agregalo ahora.
2. Tratá la capa de CDN de tu proveedor PaaS como un límite de seguridad que necesitás auditar. Conocé qué funciones son opt-in versus opt-out. Conocé cuál es el comportamiento de caché por defecto cuando no hay headers explícitos. Conocé cómo se vería un cambio de configuración accidental y si lo detectarías.
3. Suscribite a la página de estado y los postmortems de tu proveedor. No para entrar en pánico — sino porque esta es la capa de tu stack donde los cambios ocurren fuera de tu historial de git. El postmortem de Railway fue claro y detallado. El de otros proveedores puede no serlo.
El hilo de Hacker News sobre este incidente tiene comentarios contundentes, incluyendo usuarios que reportan que datos médicos quedaron expuestos en sus aplicaciones durante la ventana. Ya sea que esos reportes estén verificados o no, la dirección del riesgo es clara: contenido autenticado cacheado en el edge es un problema de datos personales, un problema de compliance, y en algunos verticales, un problema regulatorio.
Las plataformas PaaS no son capas mágicas de seguridad. Son infraestructura. Tratálas como tal.
Fuente: Informe de Incidente de Railway — 30 de marzo de 2026