O dia em que um Cliente viu o carrinho de outro utilizador: Um problema de cache na Cloudflare

Temos trabalhado cada vez mais na otimização de plataformas e-commerce e há uma tendência que temos vindo a observar nos últimos dois ou três anos e que antigamente só víamos nas grandes marcas, parece existir finalmente uma preocupação generalizada com o desempenho dos websites.

Para nós a performance tem sido uma luta de há muitos anos e, honestamente, nunca entendemos porque demorou tanto tempo a ganhar a atenção que merece. Talvez uma das razões esteja na evolução do próprio mercado. Hoje, com plataformas como Squarespace ou Shopify, é relativamente simples lançar um website com um design profissional e tornou-se mais difícil para as marcas diferenciarem-se apenas pelo aspeto.

Quando é fácil ter uma presença visualmente apelativa, começam a ganhar peso outros fatores. A velocidade de carregamento, a experiência de navegação, a estabilidade e a capacidade de suportar picos de tráfego passaram a ser elementos que importam.

Foi precisamente nesta altura que nos apareceu um caso que mostra bem o outro lado da questão e que ilustra bem como a procura por mais desempenho pode criar problemas sérios.

Clientes a ver dados de outros utilizadores

Fomos contactados por uma marca, que podemos considerar de média dimensão, que começou a receber reclamações invulgares. Alguns clientes autenticados estavam a ver informações que não lhes pertenciam: nomes de outros clientes, carrinhos com produtos inesperados e, em alguns casos, dados relacionados com processos de compra em curso.

Tentámos fazer um diagnóstico rápido e perceber se isso alguma vez tinha acontecido anteriormente. A resposta foi negativa. Procurámos perceber se tinha existido alguma atualização recente à plataforma e também nos indicaram que não.

Até que nos chamou a atenção um detalhe: o website parecia estar a ser routeado via Cloudflare. Questionámos e indicaram que tinha sido uma atualização recente feita pelo responsável de IT para evitar um pico de bots que deixaram o site inoperacional durante algum tempo. Soubemos instantaneamente do que se tratava. Apenas nunca tínhamos visto este problema acontecer de forma tão grave.

O que estava realmente a acontecer

O cenário que encontrámos é mais comum do que se pensa, mas é raro ter esta dimensão sem ser detetado. Para responder ao ataque de bots e tentar acelerar o site de forma imediata, tinha sido ativada uma regra de cache global na Cloudflare para o domínio.

Na prática, a Cloudflare estava a fazer exatamente aquilo que lhe tinham pedido que era guardar todas as respostas que recebia da origem. O problema é que algumas dessas respostas continham informação personalizada.

O fluxo era semelhante a este:

1. Um utilizador autenticado visitava uma página da loja.
2. O servidor gerava uma página HTML com informação específica dessa sessão, incluindo nome do utilizador, produtos no carrinho, etc.
3. A Cloudflare interceptava e armazenava essa resposta nos seus servidores.
4. O visitante seguinte quando acedia, recebia essa mesma versão da página diretamente da Cloudflare, sem que fosse gerado novo conteúdo no servidor.

Como Corrigimos o Problema Sem Perder Performance

Não foi necessário alterar nada no website nem redesenhar a infraestrutura, mantivemos a Cloudflare porque o problema estava concentrado apenas na estratégia de cache.

Para resolver implementámos duas medidas simples:

1. Diferenciámos utilizadores anónimos de utilizadores autenticados

A primeira medida foi substituir a regra genérica por regras mais específicas. Passámos a analisar a presença de cookies de autenticação e sessão antes de permitir que a Cloudflare servisse conteúdo a partir da cache.

A lógica aplicada foi semelhante à seguinte:

(http.request.uri.path matches "^/loja/.*"
  and (http.cookie contains "PHPSESSID"
    or http.cookie contains "client_session"))

Sempre que estes cookies estavam presentes, o pedido era encaminhado diretamente para o servidor.

Desta forma, visitantes anónimos continuavam a beneficiar da cache da Cloudflare, enquanto utilizadores autenticados passaram a receber conteúdo gerado em tempo real.

2. Reforçámos as diretivas de cache no servidor

Não gostamos de depender exclusivamente das regras configuradas nos painéis dos CDNs, por isso, ajustámos também os cabeçalhos HTTP emitidos pelo próprio servidor do nosso cliente.

Para conteúdos públicos, como artigos, páginas institucionais ou catálogo sem personalização, utilizámos diretivas como:

Cache-Control: public, max-age=3600, s-maxage=86400

Já para checkout, áreas de cliente e outras páginas dependentes da sessão, definimos:

Cache-Control: private, no-cache, no-store, must-revalidate

Desta forma, qualquer proxy intermédio passou a receber instruções claras sobre o que pode e não pode ser armazenado. Se amanhã mudarem da Cloudflare para outro, à partida, este problema não se volta a repetir.

O Que Vale a Pena Reter

Este caso é um bom exemplo de como uma alteração feita com o objetivo certo pode acabar por criar um problema complexo. Uma preocupação legítima com o facto de o site estar a sofrer com um pico de bots trouxe um problema que podia ter trazido consequências sérias para a marca.

Não somos contra colocar conteúdo em cache, muito pelo contrário. Em muitos projetos é uma das melhores formas de ganhar performance, mas é importante perceber o que pode ser colocado em cache. Uma página de produto pode ser igual para milhares de visitantes, já o carrinho, a conta de cliente ou um checkout não podem.

Por isso, acreditamos mesmo que antes de fazer alterações deste género, a configuração deve ser analisada por uma equipa com experiência em infraestrutura, performance e segurança. Muitas vezes, pequenas alterações na forma como o CDN está configurado são suficientes para resolver um problema de performance, mas é importante perceber primeiro o impacto que essas alterações podem ter.

Neste caso conseguimos manter a Cloudflare e os benefícios de performance que procurávamos, sem comprometer a experiência nem a segurança dos utilizadores.