Los endpoints GET que cambian el estado son la principal fuente de acciones no deseadas desencadenadas por clientes automatizados

Hipótesis

El RFC 9110 define GET, HEAD, OPTIONS y TRACE como métodos seguros, es decir, esencialmente de solo lectura, y afirma que el objetivo de esta distinción es que los procesos automáticos de recuperación y la precarga (prefetching) funcionen sin riesgo de causar daño. Usa page?do=delete como ejemplo y exige que el propietario del recurso rechace estas acciones cuando lleguen a través de un método seguro; además, advierte de los efectos secundarios cuando procesos automáticos hacen un GET a cada URI que encuentran. La sección sobre idempotencia añade que las solicitudes idempotentes pueden repetirse automáticamente tras un fallo de comunicación. Por tanto, todo cliente que se comporte conforme a la especificación, desde la precarga de un navegador hasta una pasarela de correo que sigue los enlaces para comprobarlos, ejecutará lo que sea que un GET desencadene.

La hipótesis: en una aplicación con acciones desencadenadas por GET, la proporción de acciones «fantasma», definidas como entradas de auditoría sin una sesión interactiva asociada, está dominada por estos clientes automatizados y cae a casi cero cuando esas mismas acciones exigen POST (una página de aterrizaje por GET con un formulario POST, o un token de un solo uso que se consume únicamente con POST).

Predicción

Las ejecuciones de acciones desencadenadas por GET mostrarán, con una frecuencia muy superior a la de las acciones desencadenadas por POST en el mismo sitio: user agents de escáneres y prefetchers, solicitudes a los pocos segundos de entregarse un correo y solicitudes sin la cookie de sesión de la aplicación. Tras la conversión a POST, la tasa de acciones fantasma de esas acciones disminuye; los duplicados que queden en endpoints POST se deberán a reintentos de clientes sin claves de idempotencia, no a prefetchers.

Prueba propuesta

1. Inventariar todas las acciones accesibles por GET: tablas de rutas, plantillas de correo con enlaces de acción, atajos de administración.
2. Durante un periodo fijo, registrar por cada ejecución: método, user agent, presencia de cookie de sesión, referrer y tiempo transcurrido desde el envío del correo que contiene el enlace.
3. Clasificar las ejecuciones como interactivas o automatizadas a partir de esas señales; calcular la tasa de acciones fantasma por acción.
4. Convertir la mitad de las acciones (elegidas al azar) a POST con un paso de confirmación; dejar el resto sin cambios durante el mismo periodo.
5. Comparar las tasas de acciones fantasma por acción antes y después, y entre los dos grupos; informar de los recuentos y no solo de las tasas, e indicar los tipos de cliente identificados.

Estado

No se afirma ningún resultado. Entre los factores de confusión están el bloqueo de bots o la limitación de tasa introducidos al mismo tiempo, los cambios en la caducidad de los tokens y los clientes automatizados que ejecutan JavaScript y envían formularios, a los que la conversión no detendría.