En resumen
Qué se comprueba
si el formulario envía los datos cifrados y si tiene alguna protección frente a envíos automáticos.
Cuándo salta
cuando el envío es inseguro, o cuando no hay ninguna protección antispam.
Por qué importa
los datos que alguien escribe viajan legibles, y el navegador se lo dice en pantalla.
Severidad en Wakaris
Mejora. Aparece en el 16,9 % de las páginas analizadas, cifra interna del catálogo y contada sobre todas las páginas, también las que no tienen formularios.
Qué es y qué comprueba este hallazgo
Wakaris llama Protección de formularios a la revisión de dos propiedades distintas de un mismo elemento: adónde van los datos que alguien escribe en tu formulario, y si hay algo que impida que ese formulario se rellene solo, miles de veces, desde un programa.
La comprobación se apoya en tres evidencias. La primera registra si la página tiene formularios, y es la que decide si las otras dos tienen sentido: en una página sin formularios no hay nada que proteger. La segunda mira el envío, es decir si los datos salen cifrados o en claro. La tercera mira si existe alguna protección frente a envíos automáticos.
El hallazgo se dispara en dos situaciones y el informe te dice cuál: el envío es inseguro, o no hay protección antispam. Son dos problemas de naturaleza muy distinta bajo un mismo nombre, así que conviene leer la evidencia antes de decidir qué hacer.
Cómo se comprueba
Wakaris analiza la URL que le indiques, localiza los formularios de esa página y te devuelve si el envío es seguro y si hay alguna protección antispam, con la severidad del hallazgo y sin instalar nada. Esa es la vía directa para saber en qué punto estás.
Conviene saber qué alcance tiene la comprobación, porque cambia cómo se lee el resultado. Se hace sobre una sola página y una sola carga: un formulario que solo aparece tras iniciar sesión, o que se monta más tarde desde JavaScript, queda fuera. Y comprueba presencia, no eficacia: que exista una barrera antispam no dice que funcione, igual que un envío cifrado no garantiza que quien recibe los datos los trate bien.
Hay dos cosas que la definición del check no concreta y que conviene confirmar con el equipo antes de discutir un resultado: qué mecanismos cuenta como protección antispam válida, y si el envío se juzga solo por la dirección declarada en el formulario o también por lo que hace el código que lo procesa.
Por qué importa
Importa por dos motivos que no tienen nada que ver entre sí.
El primero es que los datos viajan legibles. La documentación de MDN lo dice sin rodeos: si el formulario está en una página segura y su dirección de envío apunta a una URL http insegura, todos los navegadores muestran un aviso de seguridad al usuario cada vez que intenta enviar datos, porque los datos no irán cifrados. Ese aviso lo ve tu cliente justo cuando escribe su teléfono. Y desde enero de 2017, Chrome marca además como no segura cualquier página que pida una contraseña o una tarjeta fuera de un contexto seguro; meter el formulario en un marco https dentro de una página http no basta, porque la página de primer nivel también tiene que ser https.
El segundo es el spam automatizado, que OWASP cataloga como amenaza propia con el código OAT-017: la adición de información maliciosa o cuestionable a contenidos o mensajes, públicos o privados. Incluye malware, propiedad intelectual robada, código de seguimiento y contenido publicado para posicionar o para tapar otras publicaciones.
Causas comunes
En el envío inseguro, la causa dominante es una migración a https hecha a medias. La página se pasó a https y la dirección de envío del formulario se quedó escrita a mano con http en la plantilla. El formulario sigue funcionando, así que nadie lo mira. Le siguen los formularios que envían a un servicio externo o a un gestor de contactos antiguo que solo responde por http.
En la falta de protección antispam hay tres patrones. El formulario nació como un contacto rápido y nunca se le añadió nada. La barrera existió y se quitó a propósito, porque perdía conversiones o se rompía en móvil. O lo que hay es validación en el navegador: comprobaciones que impiden enviar el formulario mal rellenado, pero que un programa se salta mandando los datos directamente al destino, sin abrir la página.
Cómo solucionarlo
Por orden de esfuerzo frente a resultado.
Primero, arregla la dirección de envío. Wakaris te señala qué formulario falla; pásala a https o déjala relativa para que herede el esquema de la página. Y si recoge algo sensible, no lo mandes por GET: MDN advierte de no usar nunca ese método para una contraseña, porque acaba visible en la barra de direcciones.
Segundo, pon una barrera que no castigue a quien rellena. La nota del W3C sobre la inaccesibilidad de los CAPTCHA recomienda los enfoques no interactivos, porque no plantean ningún reto de accesibilidad, y cita los campos trampa ocultos y el filtrado de spam en el servidor. Si usas un desafío visual, tiene que haber alternativa.
Tercero, valida en el servidor: la regla de MDN no admite matices, todos los datos que llegan tienen que comprobarse y sanearse sin excepción.
Cuarto, cierra la puerta con una cabecera. La directiva form-action de Content Security Policy restringe las URL que pueden ser destino de un envío. Después, vuelve a pasar la página por Wakaris.
Tabla con las dos situaciones que disparan el hallazgo, la evidencia asociada a cada una y el arreglo correspondiente
Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris. Tema: Tabla con las dos situaciones que disparan el hallazgo, la evidencia asociada a cada una y el arreglo correspondiente. Estilo: fondo blanco con lavado suave lima→verde pálido (#F8F7D6 → #E2F2DC), acento en degradado verde→lima (#8ED390 → #DCD86F), tinta casi negra (#12150B), formas de pastilla y esquinas redondeadas, sombras difusas, aspecto limpio y esquemático, sin fotografía. Formato: 16:9, 1440 píxeles de ancho. Sin texto legible: cualquier rótulo, código o cifra se representa con barras grises de relleno. El significado lo lleva el pie de foto, no la imagen. Sin logotipos reales ni marcas de terceros. Sin personas reconocibles. Etiquetas: protección, formularios, tabla, situaciones, disparan, hallazgo, evidencia, asociada
Pregúntale a tu IA
Si quieres profundizar en tu caso concreto, copia uno de estos dos prompts y pégalo en la IA que uses. Elige según tu situación.
Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo
Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada. Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El hallazgo es: Protección de formularios. Revisa los formularios de una página y comprueba dos cosas: si envían los datos por una conexión cifrada y si tienen alguna barrera frente a envíos automáticos. Referencia: el hallazgo salta cuando el envío es inseguro, o cuando no hay ninguna protección antispam. Pega aquí el resultado de Wakaris: qué evidencia te ha salido en rojo (envío inseguro o falta de protección antispam), en qué página y, si lo indica, en qué formulario. Si no lo tienes, dímelo y te diré cómo obtenerlo antes de seguir. Reglas que debes seguir en todo momento: 1. No asumas nada sobre mi web. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya medido. Si no lo sabes, pregúntamelo antes de afirmarlo. 2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber si este hallazgo me afecta de verdad y por dónde: a) ¿En qué plataforma está tu web? (WordPress, Shopify, web a medida, otra) b) ¿Cuántos formularios tiene la página afectada y para qué sirve cada uno (contacto, alta en boletín, presupuesto, acceso con contraseña, pago)? c) ¿Qué datos recoge el formulario afectado? ¿Hay contraseñas, datos de pago, documentos de identidad o datos de salud? d) ¿Sabes adónde envía los datos: a tu propia web, a un servicio externo de formularios, a un gestor de contactos o a un correo? e) ¿Tiene ahora mismo alguna protección contra envíos automáticos? ¿Sabes cuál? f) ¿Recibes envíos basura por ese formulario? ¿Muchos o alguno suelto? g) Si hay que aplicar un arreglo técnico, ¿lo harías tú, un técnico interno o una agencia? 3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas algo, explícame por qué aplica a mi caso. 4. Marca siempre tu nivel de certeza. Si algo es una hipótesis porque no lo puedes medir, dilo: tú no ves mi web, razonas sobre lo que yo te cuento. 5. No me propongas cambios técnicos irreversibles o de riesgo (configuración de servidor, borrar recursos, cambios directos en producción) sin avisarme antes del riesgo y de que conviene una copia de seguridad o un entorno de prueba. 6. No me propongas probar el formulario enviando datos personales de terceros ni lanzar envíos masivos contra mi propia web para ver si aguanta. Si hace falta una prueba, dime cómo hacerla con datos inventados y en un entorno de prueba. 7. Si necesitas un dato que solo se obtiene analizando la web (confirmar qué formulario falla, o si el arreglo funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se comprueba, no se adivina. 8. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí. 9. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo, ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona. Fuente de este hallazgo: https://www.wakaris.com/es/guias/seguridad/proteccion-de-formularios Para comprobarlo o volver a comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Aún no lo he medido y quiero comprobar si mi web tiene este problema
Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho. Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El problema que quiero investigar es: Protección de formularios. Se trata de si los formularios de mi página envían los datos por una conexión cifrada y de si tienen alguna barrera frente a envíos automáticos. Referencia: el problema existe cuando el envío es inseguro, o cuando no hay ninguna protección antispam. Todavía NO sé si mi web lo tiene: quiero averiguarlo. Reglas que debes seguir en todo momento: 1. Lo primero y más importante: esto se COMPRUEBA leyendo el código de mi página, y tú no puedes hacerlo desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente. 2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga el problema: a) ¿Tu web tiene formularios? ¿Cuáles y en qué páginas (contacto, boletín, presupuesto, acceso, pago)? b) ¿Qué datos pide cada uno? ¿Alguno pide contraseña o datos de pago? c) ¿Tu web carga con el candado del navegador, es decir por https? ¿La migraste en algún momento desde http? d) Cuando envías el formulario tú mismo para probarlo, ¿el navegador te muestra algún aviso de que la información no es segura? e) ¿Los formularios los hizo la misma persona que la web, o vienen de un servicio externo o de un plugin? f) ¿Recibes envíos basura por esos formularios? ¿Cuántos al día, más o menos? g) ¿En qué plataforma está la web? (WordPress, Shopify, web a medida, otra; o no lo sé) 3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, y de cuál de las dos cosas sería la sospechosa, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico. 4. Dime de forma directa que la única manera de saberlo de verdad es comprobarlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dirá qué formulario falla, en qué evidencia y de paso el estado de las otras áreas. 5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes, pero recuérdame que Wakaris lo hace más rápido, sobre la página real y con información adicional que a mano no obtengo. 6. No me propongas lanzar envíos masivos ni pruebas de ataque contra mi propia web para averiguarlo. 7. Si al comprobarlo resulta que sí lo tengo, dime que el siguiente paso es entender cómo me afecta y cómo solucionarlo en mi caso concreto. 8. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme. Fuente de este hallazgo: https://www.wakaris.com/es/guias/seguridad/proteccion-de-formularios Para comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Preguntas frecuentes
¿Por qué me sale este hallazgo si mi web ya es https? +
Porque una cosa es dónde está la página y otra adónde envía el formulario. La dirección de envío puede seguir apuntando a http aunque la página cargue por https. MDN documenta que, en ese caso, todos los navegadores avisan al usuario cada vez que intenta enviar los datos, porque no irán cifrados.
¿Basta con validar el formulario en el navegador? +
No. Esa validación mejora la experiencia de quien rellena, pero un programa no abre tu página: manda los datos directamente a la dirección de destino y nunca ejecuta ese código. La comprobación que sirve contra el spam automatizado es la que ocurre en el servidor, cuando los datos ya han llegado.
¿Tengo que poner un CAPTCHA para pasar esta comprobación? +
No necesariamente. El W3C recoge que resolver uno lleva una media de 32 segundos y que los enfoques no interactivos, como un campo trampa oculto o el filtrado en el servidor, no plantean ningún reto de accesibilidad. Cualquier barrera efectiva vale, y la que exige demostrar que no eres un programa tiene coste.
¿Un formulario que envía sin cifrar y uno sin antispam son el mismo hallazgo? +
Sí, son la misma comprobación con la misma severidad, porque la severidad es un atributo del check y no del caso concreto. Lo que te dice cuál de los dos tienes es la evidencia que acompaña al hallazgo en el informe. El arreglo, en cambio, no se parece en nada.
Fuentes citadas
- developer.mozilla.orgSending form data, MDN: el aviso de todos los navegadores cuando la dirección de envío es http insegura, la prohibición de GET para contraseñas y la regla de comprobar y sanear todo dato que llega al servidor.
- developer.mozilla.orgMixed content, MDN: definición de contenido mixto y reparto entre peticiones que el navegador eleva a https y peticiones que bloquea.
- developer.chrome.comAvoiding the not secure warning in Chrome, Chrome for Developers: marcado como no segura de las páginas con campos de contraseña o tarjeta fuera de contexto seguro desde enero de 2017, e insuficiencia del marco https dentro de página http.
- owasp.orgOAT-017 Spamming, OWASP: definición del spam como amenaza automatizada y tipos de contenido que introduce.
- w3.orgInaccessibility of CAPTCHA, W3C: media de 32 segundos para resolver un CAPTCHA y recomendación de los enfoques no interactivos, campos trampa y filtrado de spam.
- developer.mozilla.orgContent-Security-Policy: form-action, MDN: la directiva restringe las URL que pueden ser destino de un envío de formulario.
Actualizado: 8 de septiembre de 2026.
Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.