Ontem, Railway publicou um dos relatórios de incidentes mais desconfortáveis que li em muito tempo. Entre 10:42 e 11:34 UTC em 30 de março, uma atualização de configuração em seu CDN ativou acidentalmente o cache para aproximadamente 0,05% dos domínios que haviam explicitamente optado por não usar a funcionalidade de CDN do Railway. Durante 52 minutos, respostas HTTP GET — incluindo as autenticadas — foram armazenadas na edge e potencialmente servidas a usuários diferentes do solicitante original. Alguns usuários viram páginas destinadas a outras pessoas. Railway limpou o cache globalmente e publicou um postmortem completo no mesmo dia.
A causa raiz foi tecnicamente específica: um engenheiro do Railway ativou “Surrogate Keys” em seu provedor de CDN para habilitar invalidação de cache por domínio. Essa funcionalidade, sem que ninguém soubesse, contornou completamente o comportamento de se CDN está desativado, passar para a origem. Os headers Set-Cookie não foram cacheados — mas os corpos de resposta foram. E o corpo é onde está o dano.
Essa distinção merece seu próprio parágrafo.
A Armadilha do Cookie Não É a Única Armadilha
Existe um modelo mental muito difundido entre desenvolvedores que diz: “se não estou cacheando cookies, minhas sessões estão seguras.” O incidente do Railway quebra esse modelo de forma clara. Seu cookie de sessão pode estar perfeitamente isolado, mas a resposta HTTP autenticada — aquela que contém o nome do seu usuário, seu status de faturamento, identificadores de workspace, tokens CSRF embutidos em formulários, ou o JSON que inicializa o frontend — esse corpo de resposta pode ser cacheado e servido para a pessoa errada. Você pode proteger o cookie e ainda assim vazar a página.
A proteção padrão são headers Cache-Control explícitos em qualquer resposta que contenha conteúdo específico do usuário: Cache-Control: no-store, no-cache, private. Se sua aplicação não emite esses headers nas rotas autenticadas, você está implicitamente confiando no comportamento padrão do seu provedor de infraestrutura — e esse comportamento padrão pode mudar, ser mal configurado, ou falhar exatamente dessa forma.
Isso não é um cenário hipotético. Acabou de acontecer.
A Camada de Conveniência do PaaS Tem Sua Própria Superfície de Ataque
Quero ser preciso aqui: isso não é uma condenação do Railway. Eles publicaram um postmortem transparente, notificaram os usuários afetados, limparam o cache rapidamente e delinearam medidas preventivas concretas — testes adicionais de comportamento de cache antes de mudanças em produção, e rollouts de CDN escalonados em horas em vez de minutos. Essa é a postura correta diante de um incidente.
O ponto mais amplo é arquitetônico. As plataformas PaaS abstraem uma complexidade enorme: DNS, TLS, roteamento, entrega na edge, mitigação de DDoS. Essa abstração tem valor genuíno. Mas também significa que uma mudança de configuração dentro de uma camada do provedor que você não controla — uma que talvez você nem soubesse que existia — pode alterar as propriedades de segurança da sua aplicação sem que sua aplicação mude em absoluto.
Railway tinha um guard (CDN desativado → passar para a origem). Uma mudança de engenharia legítima a contornou. As aplicações implantadas nesses domínios afetados não tiveram visibilidade sobre isso. Nenhum código mudou do lado da aplicação. O comportamento mudou na camada de infraestrutura.
O Que Isso Significa para Sua Stack
Três lições práticas deste incidente:
1. Estabeleça headers de cache explícitos em cada rota autenticada. Não dependa dos padrões da plataforma. Cache-Control: no-store em qualquer resposta que contenha conteúdo com escopo de sessão não é opcional — é o piso mínimo. Se seu framework ou middleware não o define para respostas autenticadas, adicione agora.
2. Trate a camada de CDN do seu provedor PaaS como um limite de segurança que você precisa auditar. Saiba quais funcionalidades são opt-in versus opt-out. Saiba qual é o comportamento de cache padrão quando não há headers explícitos. Saiba como ficaria uma mudança de configuração acidental e se você a detectaria.
3. Inscreva-se na página de status e nos postmortems do seu provedor. Não para entrar em pânico — mas porque essa é a camada da sua stack onde as mudanças ocorrem fora do seu histórico de git. O postmortem do Railway foi claro e detalhado. O de outros provedores pode não ser.
A thread no Hacker News sobre esse incidente tem comentários contundentes, incluindo usuários relatando que dados médicos ficaram expostos em suas aplicações durante a janela. Independentemente de esses relatos estarem verificados ou não, a direção do risco é clara: conteúdo autenticado cacheado na edge é um problema de dados pessoais, um problema de compliance, e em alguns setores, um problema regulatório.
As plataformas PaaS não são camadas mágicas de segurança. São infraestrutura. Trate-as como tal.
Fonte: Relatório de Incidente do Railway — 30 de março de 2026