¿Los datos enviados por HTTP POST están ocultos o son más seguros que por GET?
Respuesta breve
No. POST simplemente lleva los parámetros en el cuerpo de la petición en vez de en la URL; ese cuerpo va en texto plano y es totalmente visible para quien pueda ver el tráfico, salvo que se use HTTPS. POST es preferible para acciones que cambian el estado y mantiene los parámetros fuera de URL, registros e historial, pero no aporta confidencialidad por sí mismo. El error confunde «no está en la URL» con «cifrado» — solo TLS cifra los datos de cualquiera de los dos métodos en tránsito.
Un número sorprendente de desarrolladores cree que POST «oculta» los datos. No cifra nada. Entender por qué es una prueba limpia de si alguien capta la diferencia entre transporte y cifrado.
Por qué la respuesta popular es incorrecta
En la red, una petición POST se ve así: línea de petición, cabeceras, una línea en blanco y luego el cuerpo con tus parámetros — como texto legible. Una petición GET pone esos parámetros en la cadena de consulta de la URL. En ambos casos, si la conexión es HTTP simple, cualquiera que observe el tráfico — un sniffer de red, un punto Wi-Fi malicioso, un proxy transparente — lee los valores directamente. POST cambia dónde está el dato, no si está cifrado. Afirmar que POST está «cifrado» o que sus parámetros son «secretos ante los proxys» porque no se registran es sencillamente falso; un proxy que termina o inspecciona la conexión ve todo el cuerpo.
Qué te aporta POST realmente
POST tiene ventajas reales, pero no la confidencialidad. Como los parámetros no van en la URL, no acaban en el historial del navegador, los registros de acceso del servidor, los marcadores ni la cabecera Referer enviada a terceros — todos lugares donde una cadena de consulta GET puede filtrarse. POST es además el método correcto para acciones que cambian el estado (no se espera que sea seguro ni idempotente) y evita los límites de longitud de URL. Buenas razones para usarlo, pero de higiene y semántica, no de criptografía.
La solución real: TLS
Lo único que hace confidencial a cualquiera de las dos peticiones es HTTPS / TLS, que cifra toda la petición — método, cabeceras, URL y cuerpo — entre el navegador y el servidor. Bajo TLS, los cuerpos de GET y POST quedan protegidos de los espías en el camino. Aun así, prefiere POST para los secretos, porque una URL de una petición GET todavía puede aparecer en registros e historial tras el descifrado. El resumen listo para entrevista: POST saca el dato de la URL; TLS lo hace secreto. Confundir ambos es la trampa.
Posibles preguntas de seguimiento
- ¿Qué cifra realmente el cuerpo POST en tránsito, y en qué capa?
- ¿Por qué enviar una contraseña en una cadena de consulta GET sigue siendo mala idea incluso con HTTPS?
- ¿Dónde pueden filtrarse los parámetros GET donde los POST normalmente no lo harán?