Endpoints GET que alteram estado são a principal fonte de ações não intencionais disparadas por clientes automatizados

Hipótese

A RFC 9110 define GET, HEAD, OPTIONS e TRACE como métodos seguros, ou seja, essencialmente somente leitura, e afirma que o objetivo dessa distinção é permitir que processos automatizados de recuperação e o pré-carregamento (pre-fetching) funcionem sem risco de causar dano. Ela usa page?do=delete como exemplo e exige que o dono do recurso rejeite essas ações quando chegam por um método seguro, alertando para os efeitos colaterais quando processos automatizados fazem um GET em cada URI que encontram. A seção sobre idempotência acrescenta que requisições idempotentes podem ser repetidas automaticamente após uma falha de comunicação. Portanto, todo cliente que se comporta conforme a especificação, desde o prefetch de um navegador até um gateway de e-mail que segue links para verificá-los, executará tudo o que um GET disparar.

A hipótese: em uma aplicação com ações disparadas por GET, a proporção de ações "fantasma", definidas como entradas de auditoria sem sessão interativa correspondente, é dominada por esses clientes automatizados e cai para quase zero quando as mesmas ações passam a exigir POST (uma página de destino via GET com um formulário POST, ou um token de uso único consumido somente via POST).

Previsão

As execuções de ações disparadas por GET mostrarão, em taxa muito superior à das ações disparadas por POST no mesmo site: user agents de scanners e prefetchers, requisições feitas poucos segundos após a entrega de um e-mail e requisições sem o cookie de sessão da aplicação. Após a conversão para POST, a taxa de ações fantasma dessas ações diminui; as duplicatas que restarem em endpoints POST se devem a retentativas de clientes sem chaves de idempotência, e não a prefetchers.

Teste proposto

1. Inventariar todas as ações acessíveis por GET: tabelas de rotas, templates de e-mail com links de ação, atalhos administrativos.
2. Durante um período fixo, registrar por execução: método, user agent, presença de cookie de sessão, referrer e tempo decorrido desde o envio do e-mail que continha o link.
3. Classificar as execuções como interativas ou automatizadas com base nesses sinais; calcular a taxa de ações fantasma por ação.
4. Converter metade das ações (escolhidas aleatoriamente) para POST com uma etapa de confirmação; deixar as demais inalteradas durante o mesmo período.
5. Comparar as taxas de ações fantasma por ação antes e depois e entre os dois grupos; relatar as contagens, não apenas as taxas, e listar os tipos de cliente identificados.

Estado

Nenhum resultado é afirmado. Entre os fatores de confusão estão bloqueio de bots ou limitação de taxa (rate limiting) introduzidos ao mesmo tempo, mudanças na expiração de tokens e clientes automatizados que executam JavaScript e enviam formulários, que a conversão não impediria.