GET vs POST: ¿por qué POST no es más seguro?

En clase, los formularios que hicimos no llegaban a ningún sitio de verdad — trabajamos con páginas estáticas, solo HTML y CSS, porque ASIR no se centra en desarrollo web. Ningún action="servicio.php" de nuestros ejercicios tenía un servidor real esperando al otro lado. Pero el profesor sí explicó cómo funciona cada método de envío por dentro, y es un concepto que merece la pena entender bien aunque no lo hayas usado en producción, porque el error de pensar que POST es “seguro” es de los más extendidos.

Cómo se envían los datos con GET

Con el método GET, todo lo que escribes en el formulario se añade directamente a la URL, como parámetros:

http://lmsgi.net/ejercicios/formulario/servicio.php?nombre=Eva+Mar%C3%ADa&apellidos=Hidalgo+Ru%C3%ADz&sexo=M

Cada campo del formulario se convierte en un par nombre=valor en la propia dirección. Esto tiene ventajas concretas: la URL resultante es compartible, se puede guardar en favoritos, y funciona con el botón de retroceder del navegador sin reenviar nada. Por eso GET es el método natural para búsquedas o filtros — que el resultado tenga una URL propia es una característica, no un problema.

Cómo se envían los datos con POST

Con POST, los mismos pares nombre=valor viajan dentro del cuerpo de la petición HTTP, no en la URL. Visualmente, la barra de direcciones se queda limpia — y ahí es donde mucha gente da el salto (equivocado) a pensar “si no se ve en la URL, es más seguro, casi como si estuviera cifrado”.

El error de pensar que POST es “seguro”

No lo es, al menos no en el sentido de protección de datos. Los datos de un formulario enviado por POST siguen siendo perfectamente visibles — solo que en un sitio distinto. Cualquiera puede verlos abriendo las herramientas de desarrollador del navegador:

Inspeccionar → Network (Red) → selecciona la petición → pestaña Headers → apartado Form Data

Ahí aparecen los mismos pares nombre-valor que en GET, sin cifrar, tal cual los escribiste. La diferencia real entre GET y POST no es “seguridad” — es dónde queda registrado el dato y qué límites tiene:

Lo que de verdad protege un dato sensible enviado por un formulario no es elegir POST en vez de GET — es que el formulario viaje sobre HTTPS, que cifra toda la comunicación (URL, cabeceras y cuerpo) entre el navegador y el servidor. Un formulario por POST sobre HTTP sigue siendo interceptable por cualquiera que esté “escuchando” en la misma red.

Qué pasa con los archivos: el atributo enctype

Hay un caso donde POST no es solo una opción, sino la única posible: cuando el formulario incluye un archivo para subir (un <input type="file">). Para eso existe el atributo enctype de la etiqueta <form>, que solo tiene sentido cuando el método es POST:

• application/x-www-form-urlencoded — el formato por defecto, válido para texto normal.
• multipart/form-data — obligatorio si el formulario envía un archivo.
• text/plain — texto plano, pensado para compatibilidad con sistemas antiguos.

Con GET no existe enctype porque no tiene sentido: no puedes meter el contenido binario de un archivo dentro de una URL.

Qué pasa por detrás en el protocolo HTTP

Tanto GET como POST son, en el fondo, métodos del protocolo HTTP — la forma en que el navegador le pide cosas a un servidor. Cuando envías un formulario, el navegador construye una petición HTTP con ese método, la manda al servidor indicado en action, y espera una respuesta. Con GET, el método y los parámetros van en la primera línea de la petición, dentro de la propia URL solicitada. Con POST, la primera línea solo indica la ruta a la que se envía, y los datos van más abajo, en el cuerpo del mensaje — es una petición HTTP con más partes, no una petición “cifrada” ni distinta en su naturaleza.

Esto explica por qué, aunque en nuestros ejercicios de clase los formularios no llegaran a ningún servidor real, el comportamiento del navegador construyendo la petición es exactamente el mismo que si hubiera un servicio.php real esperando al otro lado. El navegador no sabe ni le importa si el destino existe — simplemente construye la petición según el método indicado y la envía.

Qué pasa si repites el envío

Hay una diferencia práctica entre GET y POST que se nota mucho en el día a día, aunque no tenga que ver con seguridad: si recargas una página que llegó por GET, el navegador simplemente repite la petición sin avisar, porque GET se considera una operación “segura” en el sentido de que no debería cambiar nada en el servidor (solo consultar). Si intentas recargar una página que llegó como resultado de un POST, la mayoría de navegadores te avisan explícitamente con un mensaje tipo “¿deseas reenviar los datos del formulario?” — porque un POST normalmente implica una acción con efecto (crear algo, enviar algo), y repetirla sin querer podría duplicarla.

Cuándo usar cada uno, en la práctica

La regla que de verdad importa no es de seguridad, es de naturaleza de la acción:

• Usa GET cuando el formulario solo consulta o filtra información, y tiene sentido que el resultado tenga su propia URL (una búsqueda, un filtro de productos).
• Usa POST cuando el formulario modifica algo (crear una cuenta, enviar un mensaje, subir un archivo) o cuando los datos son demasiado largos o sensibles para ir en una URL visible y guardable en el historial.

Pon a prueba lo que has entendido

Resumen rápido

GET manda los datos en la URL, es visible, compartible y limitado en tamaño; POST los manda en el cuerpo de la petición, no aparecen en la URL, pero siguen siendo visibles con las herramientas del navegador — no es una cuestión de seguridad, es de dónde queda el dato. Lo que de verdad protege la información sensible es HTTPS, no la elección entre GET y POST. Una vez tienes claro cómo viajan los datos de un formulario, el siguiente paso lógico es qué controles concretos puedes usar dentro de él — lo tienes en los tipos de input de HTML5 y cuáles ya no deberías usar.