Cómo proteger un formulario web (spam, inyecciones, RGPD)
Un formulario web mal protegido expone a tres riesgos distintos: el spam automatizado que satura el correo, las inyecciones de código que comprometen la base de datos y el incumplimiento del RGPD en la recogida de datos personales. Estos tres riesgos se abordan con medidas diferentes y complementarias; ninguna sustituye a las demás.
El verdadero problema: un formulario es una puerta abierta al servidor
A diferencia de una página de contenido estático, un formulario acepta una entrada externa y la transmite al servidor para su procesamiento (envío de un correo, registro en una base de datos). Precisamente esa interacción lo convierte en un objetivo preferente: cada campo de entrada es un punto de acceso potencial para contenido malicioso, ya sea un simple mensaje de spam o un intento de explotación más elaborado.
Los robots que rastrean la web no eligen sitios concretos: prueban sistemáticamente todos los formularios que encuentran, buscando una vulnerabilidad explotable. Un formulario de contacto sin protección suele recibir spam a los pocos días de su publicación, a veces en cuestión de horas.
Protegerse del spam automatizado
- Añadir un campo honeypot: un campo invisible para un humano (oculto con CSS) pero que los robots rellenan automáticamente, lo que permite rechazar su envío en silencio sin gastar recursos en un captcha.
- Integrar un captcha (reCAPTCHA, hCaptcha o equivalente) en los formularios más expuestos, priorizando las versiones recientes que no obligan a los visitantes legítimos a superar una prueba visual en cada ocasión.
- Limitar la frecuencia de envío desde una misma dirección IP, para bloquear los envíos masivos automatizados.
- Comprobar el formato de los campos (email válido, número de teléfono plausible) antes de aceptar el envío.
- Filtrar enlaces y palabras clave sospechosas en el contenido del mensaje, una técnica complementaria pero nunca suficiente por sí sola.
Evitar las inyecciones de código
Una inyección se produce cuando un atacante introduce código ejecutable en un campo de formulario previsto para texto simple, con el objetivo de manipular la base de datos (inyección SQL) o ejecutar código en el navegador de otros visitantes (inyección XSS). La defensa se resume en dos principios no negociables:
- Validar y filtrar siempre los datos en el servidor, nunca solo en el navegador: una validación en el navegador puede ser fácilmente eludida por un atacante que no use el formulario tal como se muestra.
- Utilizar consultas preparadas en el código que procesa los datos del formulario, una práctica estándar que impide estructuralmente la inyección SQL, en lugar de intentar "limpiar" manualmente cada campo.
En un CMS como WordPress, estas protecciones suelen gestionarlas el núcleo del software y los plugins de formularios reconocidos, siempre que se mantengan actualizados. Un formulario programado a medida sin estas precauciones sigue siendo la configuración más arriesgada.
Cumplir el RGPD en los datos recogidos
Cualquier formulario que recoja datos personales (nombre, email, teléfono) está sujeto al RGPD, sea cual sea el tamaño del sitio. Los puntos concretos que hay que comprobar:
- El formulario solo pide los datos estrictamente necesarios para su finalidad (un formulario de contacto no necesita la fecha de nacimiento).
- Una mención clara precisa por qué se recogen los datos y quién los trata.
- Un enlace a la política de privacidad es accesible desde el formulario.
- El consentimiento para un uso secundario (una newsletter, por ejemplo) es independiente y no está premarcado.
- Los datos se conservan durante un plazo definido y se eliminan después, salvo obligación legal en sentido contrario.
Qué hace vulnerable a un formulario en la práctica
- Ausencia total de validación en el servidor, con una confianza excesiva en la validación del navegador.
- Un campo de archivo adjunto que acepta cualquier formato, lo que permite subir scripts maliciosos disfrazados de archivo adjunto.
- Mensajes del formulario mostrados sin escapar en una página de administración, abriendo la puerta a una inyección XSS diferida.
- Dirección de correo de recepción expuesta en texto plano en el código fuente de la página, lo que facilita su recolección por robots de spam.
Lo que hay que recordar
- Un formulario acumula tres riesgos distintos (spam, inyección, RGPD) que exigen cada uno una respuesta específica.
- El honeypot y el captcha reducen el spam automatizado sin eliminarlo nunca del todo.
- La validación de los datos debe hacerse siempre en el servidor; la validación solo en el navegador se puede eludir.
- Las consultas preparadas son la protección de referencia frente a las inyecciones SQL, no el filtrado manual de cada campo.
- El cumplimiento del RGPD exige recoger solo los datos necesarios, con una finalidad clara y un plazo de conservación definido.
Preguntas frecuentes
¿Basta un captcha para proteger un formulario del spam? Reduce mucho el spam automatizado sin eliminarlo del todo. Combinado con un honeypot y una validación en el servidor, cubre la mayoría de los casos en un formulario estándar.
¿Qué es una inyección SQL en un formulario? Una técnica en la que un atacante introduce código en un campo para manipular la base de datos. Se evita validando siempre los datos en el servidor y usando consultas preparadas.
¿El RGPD exige un consentimiento explícito para cada formulario? Exige un consentimiento claro e informado, con una finalidad precisada. Esto no significa una casilla para cada campo, pero el visitante debe saber por qué se recogen sus datos.
¿Hay que cifrar los datos enviados por un formulario? El HTTPS ya cifra el transporte, lo que cubre lo esencial para un formulario estándar. Un cifrado adicional en el almacenamiento se justifica sobre todo para datos sensibles.
En resumen
Proteger un formulario web exige tratar por separado el spam, las inyecciones de código y el cumplimiento del RGPD, en lugar de confiar en una sola protección para cubrir los tres. Las bases (honeypot, validación en el servidor, recogida mínima de datos) están al alcance sin necesidad de una experiencia avanzada y bastan para la mayoría de los formularios de contacto profesionales. La formula sitio web por suscripción de VeryAppi incluye formularios seguros y conformes desde el primer día.
Preguntas frecuentes
›¿Basta un captcha para proteger un formulario del spam?
Un captcha reduce mucho el spam automatizado, pero no lo elimina del todo, sobre todo frente a servicios baratos de resolución manual. Combinado con un campo honeypot y una validación en el servidor, cubre la mayoría de los casos en un formulario de contacto estándar.
›¿Qué es una inyección SQL en un formulario?
Es una técnica en la que un atacante introduce código en un campo del formulario (en lugar de una respuesta normal) para manipular la base de datos del sitio: extraer, modificar o eliminar datos. Se evita validando y filtrando sistemáticamente los datos en el servidor, nunca solo en el navegador.
›¿El RGPD exige un consentimiento explícito para cada formulario?
El RGPD exige un consentimiento claro e informado para cualquier recogida de datos personales, con una finalidad definida. Esto no significa necesariamente una casilla independiente para cada campo, pero el visitante debe saber por qué se recogen sus datos y poder oponerse fácilmente.
›¿Hay que cifrar los datos enviados por un formulario?
El HTTPS ya cifra el transporte de los datos entre el navegador y el servidor, lo que cubre lo esencial para un formulario estándar. Un cifrado adicional en el almacenamiento se justifica para datos sensibles (salud, datos bancarios), rara vez para un simple formulario de contacto.