El uso de POST ofrece las siguientes ventajas sobre GET:
Evita el historial de URL del navegador . Los datos confidenciales en el formulario no se pasan en la URL, lo que significa que los datos en el formulario no son visibles en el historial del navegador y no se pueden navegar de forma conjunta una vez enviados. (Nota: el cuerpo del formulario a veces se almacena, según el navegador y la configuración, pero generalmente no está visible).
Capacidad para pasar tokens ocultos . El uso de POST le da a su aplicación la flexibilidad de incluir más campos (hay un límite estricto en la duración de una solicitud GET), incluyendo cosas importantes como tokens CSRF, sumas de comprobación de ViewState MAC, etc. No querría mostrar estos campos en el barra de direcciones.
Menos registro . Los datos en la propia URL se guardan en un encabezado HTTP, que es más probable que sea registrado por dispositivos de red intermedios (por ejemplo, si se utiliza la descarga de SSL o la inspección profunda de paquetes), o por los registros del servidor web. IIS, por ejemplo, registra la URL completa y la cadena de consulta con todas y cada una de las solicitudes, de forma predeterminada, y esto se almacena en un archivo plano que permanece en su servidor web para siempre. Los datos en el cuerpo del formulario, por otro lado, no se registran de forma predeterminada.
Evita enviar PII a las analíticas . Si hay información confidencial en la URL, corre el riesgo de que los datos terminen siendo enviados a cualquier solución de análisis o terceros que esté utilizando. En general, los datos en el cuerpo del formulario no terminarán siendo enviados a menos que usted haya hecho un esfuerzo para codificarlos.
¿El uso de POST mitiga automáticamente el riesgo de CSRF? ¡NO! Pero, por lo general, una mitigación CSRF implicará el uso de HTTP POST + un token anti-CSRF, por lo que podría ver por qué pensarían que van juntas. Sin el token, el verbo POST no hace nada en sí mismo para mitigar CSRF a través de XSS reflejado o almacenado.