询盘表单不设防，机器人比客户先到

一张询盘表单挂上官网，最先来敲门的往往不是客户，是四处扫表单的机器人。Thales 旗下 Imperva 的年度报告统计：2024 年，自动化机器人流量占到全网流量的 51%，十年来首次超过人类；其中恶意机器人占 37%1。对一张不设防的表单来说，敲门的访客里机器人可能比人多。

表单不设防，不是「顶多收到几条垃圾」的小事，是要实实在在付出代价的；而设防也不是「装上」就完事——防线活没活着，要拿真实的攻击来验。这篇杂谈先讲不设防会付出什么，再盘点主流做法，最后说说我们自己的取舍。

速览：

• 2024 年自动化机器人占全网流量的 51%，十年来首超人类；不设防的表单，敲门的机器人可能比客户多
• 代价是三笔账：垃圾询盘淹没真实客户、无上限写入挤占存储；若表单朝外发信（如自动回信），域名信誉也会被拖垮
• 主流做法四类：过滤服务、验证码、蜜罐、限流，多数站点组合使用；没有最好的一类，只有适合的组合
• 防线会悄悄失效——装上不等于活着，要定期拿真实的攻击来检验

不设防的代价：三笔账

表单垃圾（form spam）指机器经由网页表单批量提交的恶意或垃圾内容。OWASP 在「Web 应用自动化威胁」分类里给它单列一项，和撞库、恶意爬取排在同一个清单里2。

具体收账，收的是三笔：

第一笔收在注意力上。 垃圾询盘和真实客户的留言混在同一个收件箱里，按「最新」排序，垃圾永远排最前。删一百条垃圾只花几分钟，漏看一条真询盘，可能就丢了一单生意。

第二笔收在存储上。 表单提交总要留痕：日志、数据记录、邮件副本。不设上限的写入，填的是你自己的磁盘和数据库。「表单把存储写爆」听着夸张，但只要提交无成本，写满只是时间问题。

第三笔收在信誉上——但这笔收不收，取决于表单怎么接。 提交只落服务端存储、不发邮件的，不会有这笔损失；通知邮件自己发给自己域名邮箱的，同样伤不到对外信誉——顶多把自家收件箱灌满，还是第一笔账的问题。真正要当心的是朝外发信的接法，最典型是自动回信：表单收到提交后，给提交者填的邮箱回一封确认。攻击者填上别人的地址、灌进垃圾，你的域名就在替他群发——收件方服务商和黑名单记的是你的域名，信誉跌到谷底后，连正常业务邮件都进对方垃圾箱。通知发到公共邮箱服务商的个人收件箱，同理：垃圾灌多了，过滤器学会拉黑你，真询盘的通知从此失踪。

主流做法：过滤、验证码、蜜罐与限流

行业里防表单垃圾，成熟方案大致四类，多数站点是组合着用的：

• 过滤服务（内容层）：提交内容先送反垃圾服务判定，再决定收不收。WordPress 生态的默认答案 Akismet 自称服务着数百万网站3，评论、留言这类以内容为主的场景用得很普遍。
• 验证码（交互层）：在提交前加一道「证明你是人」。老牌如 Google reCAPTCHA，新趋势是无感验证——Cloudflare 已把自家全部图形验证码换成 Turnstile，覆盖 2500 多万个网站的验证页4。
• 蜜罐（表单层）：表单里加一个人类看不见的字段，专抓「不看页面、什么都填」的脚本。零用户成本，轻量方案里一直很常用。
• 限流（频率层）：给提交频率设上限——单访客有窗口限、全站有日限，超限直接拒绝。通常与前几类叠加使用。

没有「最好的一类」，只有「适合的组合」：内容为主的表单偏过滤，能接受多一步交互的选验证码，想零打扰的从蜜罐加限流起步。

我们的次序：先轻后重

询盘表单低频但高价值：真实提交不多，每一条都不能丢。所以我们的顺序从最轻的开始，不够再加重。

第一道是蜜罐。 蜜罐几乎零成本：不加验证码、不多一秒填写时间、不依赖第三方服务，专门拦「无差别扫全互联网表单」的最低档机器人——这一档恰恰数量最大。它拦不住定向的攻击者，没关系，后面还有闸。

第二道是限流。 单访客一个时间窗内最多几条，全站每天最多进多少条：前者拦定向滥用，后者给存储兜底。超限要有明确的拒绝动作——「操作太频繁」，而不是「先收下回头再说」：对自动化流量的任何宽容，都会被立即利用。

而限流最容易被忽视的命门是：成败不在阈值设多少，在计数器认的是谁。 计数器数的那个「访客」必须是真实访客；它若在数一个不存在的东西——比如一个每来一条就换一个的地址——阈值再精密也是空的。这个坑，下一节展开。

验证码的两笔账：留给高价值操作

验证码是主流方案里拦自动化最硬的一类，我们完全不否认它的效果——只是往询盘表单上放之前，值得先算两笔账。

一是用户体验账。Cloudflare 算过：用户完成一次验证码平均要花 32 秒，按全球网民规模折算，每天约浪费 500 个人年5。对一张询盘表单，这 32 秒是实打实加在「想找你聊聊」的客户身上的——每多一步，就少一批人走完。

二是通道逻辑账。真想往邮箱灌垃圾的人，绕开表单直接发邮件就行。给表单加验证码，防住的只是「只肯走表单」的攻击者，这个人群比想象中小。防线要设在绕不过去的地方。

所以验证码更适合的位置是高价值操作：注册、登录、支付、改密码。若蜜罐加限流仍不够用，再考虑无感验证（如 Turnstile 一类）——体验已远好于传统图形验证码，是加重时的首选。

防线会悄悄失效：装上不等于活着

软件里大多数故障是吵闹的：报错、崩溃、页面白屏，你很难看不见。防护恰恰相反，它的失效是静默的：代码不报错，页面一切正常，提交照单全收——没有任何东西提醒你，闸门其实已经空了。

常见的一种死法与来源地址有关。站点在 CDN 或反向代理后面时，应用看到的「来源地址」是一整条转发链，而不是访客本人。MDN 在 X-Forwarded-For 的文档里写得很直白：把这个头用于限流、访问控制这类安全用途时，只能信任由可信代理追加的地址，否则攻击者可以借它绕过限流6。一旦在链上取错了位置，计数器数的就是一个不存在的东西——每条提交都像新面孔，阈值再精密也拦不住。

更麻烦的是，防线会在你不知道的时候变弱：换了代理、调整了部署、上游网关升级，任何一环变动都可能让原本正确的假设失效。所以「上线时验证过一次」不等于「现在还活着」，拦没拦住也不该靠感觉——唯一可信的是证据：拿服务端的真实记录说话，并且定期重新打一轮。

防线装上不等于防线活着。它是否活着，只有真实的攻击能回答。

给中小企业询盘表单的设防清单

带走的清单，按性价比排序：

1. 先上蜜罐——零用户成本，拦掉数量最大的低档批量提交
2. 再上限流——单访客有窗口限、全站有日限，超限明确拒绝，别「先收着」
3. 站点在 CDN 或反向代理后面的，审一遍来源地址的取法——按可信代理的层数从链尾往回数，别想当然取头或取尾
4. 验证码留给高价值操作——询盘表单优先无感验证
5. 定期攻击自己一次——连发一串提交、翻一遍服务端记录，几分钟的事，比任何「应该没问题」都可靠

安全不是一个能「做完」的功能，是一套需要定期检验的习惯。如果你正打算给公司官网加一张询盘表单，或者已经挂了一张「从来没出过问题」的表单，不妨先问一句：它挨过打吗？这也是我们交付每张表单前的固定动作。