Spam no formulario de contacto: o día que un cliente empezou a recibir cen mensaxes falsas ao día
Un cliente que vende mobles a medida escribiunos hai un par de meses alarmado: a súa caixa de notificacións do formulario de contacto pasara de dúas ou tres mensaxes á semana a máis de cen ao día. Nada de clientes reais, claro, só ligazóns a reloxos replicados, ofertas de criptomoedas, algún texto en cirílico cun acurtador de URL detrás. O formulario levaba publicado desde a estrea da web, case un ano, sen un só filtro posto.
O spam no formulario de contacto case nunca chega porque alguén atopase a túa web en concreto: son bots que rastrean internet buscando calquera etiqueta <form> cun action que apunte a un endpoint de envío, e enchéndoa en canto a detectan. Por iso un formulario novo pode empezar a recibilo aos poucos días de publicarse, sen que teñas feito nada mal de cara ao SEO nin que ninguén te teña “fichado” especialmente.
O primeiro que fixemos foi mirar que estabamos usando de verdade, non o que cremos ter configurado. En case todos os proxectos que montamos desde hai un par de anos o formulario chama a Web3Forms — a mesma peza que usamos na nosa propia web, de feito, a mesma API que revisamos cando auditamos o noso propio servidor — e xa trae un campo honeypot e reCAPTCHA opcional de fábrica. No proxecto do showroom deixáramolo sen activar porque, naquel momento, “xa o acenderemos se fai falta”. Nunca o acendemos. Custa admitilo, pero sospeito que non é o único proxecto cun checkbox dese tipo pendente.
O honeypot que de verdade parou o spam
Activar o honeypot foi o primeiro paso, e o que máis spam tombou con diferenza: un campo de texto oculto con CSS que un humano nunca ve nin enche, pero que un bot que percorre o HTML si. Un matiz importante: mellor non ocultalo con display:none, que algúns bots xa evitan; funciona mellor movelo fóra da pantalla con position:absolute e left:-9999px. Se chega cheo, o propio backend de Web3Forms descarta o envío antes de que nos chegue o correo. Con só isto baixamos de cen mensaxes ao día a media ducia.
A media ducia que quedaba si pasaba o honeypot, así que eran bots algo máis coidadosos. Aí metemos dous filtros máis: un límite de tres envíos por hora por IP (xeneroso de sobra para calquera visitante real, por moito que insista) e un rexeitamento silencioso de calquera mensaxe cuxo campo de texto libre levase unha URL completa con http. Case ningún visitante lexítimo pega unha ligazón enteira no corpo dun formulario de contacto; calquera bot de spam, si, sempre.
Por que non metemos reCAPTCHA
Non activamos o reCAPTCHA, e isto é unha opinión que non todo o mundo comparte no oficio: o checkbox de “non son un robot” mete fricción real xusto no paso que máis lle interesa completar ao cliente, e un showroom de mobles vive de que a xente remate de enchelo formulario, non de demostrarlle a Google que é humana. Medimos a taxa de envíos completados antes e despois dos filtros novos e non baixou nin un punto, así que de momento seguimos sen el aí. Para proxectos onde o spam volve con forza a pesar do honeypot e o límite de frecuencia, si o deixamos coma último recurso: pasounos cun cliente inmobiliario que ademais arrastraba problemas de accesibilidade herdados da axencia anterior, e alí o reCAPTCHA v2 convivía mal co lector de pantalla ata que o cambiamos á versión invisible.
O que me quedou a dar voltas despois deste cliente é que levabamos meses dando por sentado que “Web3Forms xa filtra isto” sen comprobar, proxecto por proxecto, que o filtro estivese encendido de verdade. ¿Cantos outros “xa o acenderemos se fai falta” temos adormentados en webs que non volvemos abrir desde que as entregamos?