Spam en el formulario de contacto: el día que un cliente empezó a recibir cien mensajes falsos al día
Un cliente que vende muebles a medida nos escribió hace un par de meses alarmado: su buzón de notificaciones del formulario de contacto había pasado de dos o tres mensajes a la semana a más de cien al día. Nada de clientes reales, claro, solo enlaces a relojes replicados, ofertas de criptomonedas, algún texto en cirílico con un acortador de URL detrás. El formulario llevaba publicado desde el lanzamiento de la web, hacía casi un año, sin un solo filtro puesto.
El spam en el formulario de contacto casi nunca llega porque alguien haya encontrado tu web en concreto: son bots que rastrean internet buscando cualquier etiqueta <form> con un action que apunte a un endpoint de envío, y la rellenan en cuanto la detectan. Por eso un formulario nuevo puede empezar a recibirlo a los pocos días de publicarse, sin que hayas hecho nada mal de cara al SEO ni nadie te haya “fichado” especialmente.
Lo primero que hicimos fue mirar qué estábamos usando de verdad, no lo que creíamos tener configurado. En casi todos los proyectos que montamos desde hace un par de años el formulario llama a Web3Forms — la misma pieza que usamos en nuestra propia web, de hecho, la misma API que revisamos cuando auditamos nuestro propio servidor — y ya trae un campo honeypot y reCAPTCHA opcional de fábrica. En el proyecto del showroom lo habíamos dejado sin activar porque, en su momento, “ya lo encenderemos si hace falta”. Nunca lo encendimos. Cuesta admitirlo, pero sospecho que no es el único proyecto con un checkbox de ese tipo pendiente.
El honeypot que de verdad frenó el spam
Activar el honeypot fue lo primero, y lo que más spam tumbó con diferencia: un campo de texto oculto con CSS que un humano nunca ve ni rellena, pero que un bot que recorre el HTML sí. Un matiz importante: mejor no ocultarlo con display:none, que algunos bots ya evitan; funciona mejor moverlo fuera de la pantalla con position:absolute y left:-9999px. Si llega relleno, el propio backend de Web3Forms descarta el envío antes de que nos llegue el correo. Con solo esto bajamos de cien mensajes al día a media docena.
La media docena que quedaba sí pasaba el honeypot, así que eran bots algo más cuidadosos. Ahí metimos dos filtros más: un límite de tres envíos por hora por IP (generoso de sobra para cualquier visitante real, por mucho que insista) y un rechazo silencioso de cualquier mensaje cuyo campo de texto libre llevara una URL completa con http. Casi nadie legítimo pega un enlace entero en el cuerpo de un formulario de contacto; cualquier bot de spam, sí, siempre.
Por qué no metimos reCAPTCHA
No activamos el reCAPTCHA, y esto es una opinión que no todo el mundo comparte en el gremio: el checkbox de “no soy un robot” mete fricción real justo en el paso que más le interesa completar al cliente, y un showroom de muebles vive de que la gente termine de rellenar ese formulario, no de demostrarle a Google que es humana. Medimos la tasa de envíos completados antes y después de los filtros nuevos y no bajó ni un punto, así que de momento seguimos sin él ahí. Para proyectos donde el spam vuelve con fuerza pese al honeypot y el límite de frecuencia, sí lo dejamos como último recurso: nos pasó con un cliente inmobiliario que además arrastraba problemas de accesibilidad heredados de la agencia anterior, y ahí el reCAPTCHA v2 convivía mal con el lector de pantalla hasta que lo cambiamos a la versión invisible.
Lo que me quedó rondando después de este cliente es que llevábamos meses dando por sentado que “Web3Forms ya filtra esto” sin haber comprobado, proyecto por proyecto, que el filtro estuviera encendido de verdad. ¿Cuántos otros “ya lo activaremos si hace falta” tenemos dormidos en webs que no hemos vuelto a abrir desde que las entregamos?