Métodos, idempotencia y códigos de estado

La especificación de la semántica de HTTP (RFC 9110) clasifica los métodos con dos propiedades. Un método seguro es de solo lectura por definición: quien lo envía no espera cambiar nada en el servidor. Son seguros GET, HEAD, OPTIONS y TRACE. Un método idempotente puede repetirse y el efecto final es el mismo que si se hubiera enviado una vez: lo son todos los seguros y, además, PUT y DELETE (borrar dos veces el mismo recurso deja el mismo resultado que borrarlo una vez).

Esto importa al auditor por una razón práctica: navegadores, proxies y clientes reintentan o adelantan peticiones idempotentes sin preguntar, porque la especificación les dice que pueden. Si la aplicación cambia datos con un método que el resto del mundo considera repetible o de solo lectura, alguien acabará disparando ese cambio sin querer.

Que un GET cambie datos es un fallo de diseño aunque funcione. Un enlace de ese tipo lo puede seguir un buscador que indexa la página, una extensión que precarga enlaces para ir más rápido, una vista previa de un chat o una página ajena que lo incrusta como imagen; en todos esos casos el cambio ocurre sin que la persona lo decida. Lo correcto es que toda acción que cambia estado vaya por POST (o PUT, PATCH, DELETE) y con su protección contra peticiones no deseadas, que se estudia más adelante en la ruta.

Abre registro-acceso.log. Cada línea dice quién, cuándo, qué método, qué ruta y qué respondió el servidor. Busca una acción de la lista de deseos.

El primer dígito del código de estado dice la familia: 1xx informativo, 2xx éxito, 3xx redirección (el navegador debe ir a otra parte), 4xx error atribuible a la petición o a quien la hace, y 5xx error del servidor. Una aplicación sana tiene pocos 5xx; muchos seguidos indican que algo detrás (una API interna, una base, un servicio de pagos) está fallando, y un fallo del servidor puede dejar operaciones a medias. Por eso el auditor cuenta los 5xx y mira qué rutas tocan, antes de mirar cualquier otra cosa.

Cuenta en el registro las respuestas cuyo código empieza por 5.

Dos códigos de la familia 4xx se confunden a menudo y dicen cosas distintas. 401 significa que la petición no trae una autenticación válida: el servidor no sabe quién pregunta. 403 significa que el servidor entendió la petición y se niega a atenderla; si hay sesión, sabe quién es y aun así no le da permiso. Muchas aplicaciones web, en lugar de un 401, redirigen a la página de entrada con un 302. Leer bien el código evita informar como «control de acceso roto» lo que en realidad es un control funcionando.

En el registro, la cuenta de prueba pide /panel/inventario, y el navegador sin sesión pide /cuenta/mis-pedidos y /api/pedidos/AL-20417.

Si el servidor respondiera a un pago con la página de confirmación directamente, recargar esa página haría que el navegador ofreciera reenviar el formulario, y con él el pago. La práctica sana es la contraria: tras recibir el formulario, el servidor responde con una redirección que obliga al navegador a pedir la página siguiente con GET. Así, recargar solo repite la lectura. Entre las redirecciones hay códigos que conservan el método original y otros que lo cambian a GET; el auditor anota cuál usa cada formulario que mueve dinero.

Abre respuesta-pago.http.