官网表单的垃圾提交与安全:拦住机器人而不拦住客户
表单上线一周就开始收到垃圾内容。本文说明几种拦截手段的实际效果与副作用,以及服务端必须做的校验。
- 蜜罐字段与提交耗时检测成本几乎为零,对真实用户完全无感,应当先上这两项。
- 按 IP 限频会误伤共享出口的办公网络,需同时按手机号或邮箱去重。
- 超限应静默丢弃或延迟响应,明确提示频繁等于告诉对方阈值在哪。
- 验证码对所有真实用户都增加成本,应作为最后手段并优先选无感验证。
- 前端校验可被绕过,服务端必须重新校验并转义,否则后台打开时可能执行脚本。
表单一旦公开,很快就会收到自动提交的垃圾内容。处理不当会有两种结局:销售每天在上百条垃圾里找真线索,或者防护做得太重,真实客户也被挡在外面。
成本最低的两种手段
蜜罐字段:在表单里放一个人看不见、但程序会填的输入框,提交时如果它有值就判定为机器人。成本几乎为零,对简单脚本有效,对真实用户完全无感。
提交耗时检测:记录表单渲染到提交之间的时间,低于一两秒的基本是自动提交。真人填表不可能那么快。这两项合起来能拦掉相当一部分低级脚本。
频率限制要按多个维度
- 按 IP 限制是基础,但共享出口的办公网络下会误伤同公司的多个访客;
- 同时按提交内容限制:同一手机号或邮箱短时间内重复提交,直接去重;
- 超限的处理应当是静默丢弃或延迟响应,而不是明确提示「您提交太频繁」—— 后者等于告诉对方阈值在哪。
验证码是最后手段
验证码确实有效,但它对所有真实用户都增加了成本,在移动端尤其明显。建议的顺序是先上无感手段,观察一两周,确实拦不住再加验证码,并且优先选择无感验证而非要求用户识别图形。
如果必须用,考虑只在触发可疑条件时才弹出,而不是所有人每次都要过一遍。
服务端校验不能省
前端校验只是体验优化,绕过它只需要直接构造请求。服务端必须重新校验字段类型、长度、格式,并对内容做转义处理再入库与展示。表单内容如果会显示在后台页面上,未经转义的输入可能在管理员打开时执行脚本。
还要限制单字段长度。不设上限时,一次提交可以塞进几兆文本,既占存储也可能拖垮后台列表页。
留资内容本身是敏感数据
表单里有姓名、电话、公司信息,属于个人信息。存储、访问权限、保留期限都要有约定,导出功能要限制范围并留痕。把全部线索导出成表格随手发群里,是很常见但风险不低的做法。相关实现见企业官网定制。表单安全与留资合规通常一起评估,相关交付约定见合作流程。
常见问题
官网表单总收到垃圾提交怎么办?
先上两项无感手段:蜜罐字段(人看不见但程序会填的输入框)和提交耗时检测(渲染到提交低于一两秒判定为机器)。观察一两周,确实拦不住再考虑验证码,并优先选择无感验证而不是要求用户识别图形。
加验证码会影响转化吗?
会,尤其在移动端。验证码对所有真实用户都增加了操作成本。建议只在触发可疑条件时才弹出,而不是所有人每次都要通过,并把它放在无感手段之后作为最后一道。
表单收集的客户信息怎么存才安全?
按个人信息对待:明确存储位置与访问权限、约定保留期限、导出功能限制范围并留下操作记录。服务端必须对输入做转义后再入库与展示,否则未经处理的内容可能在管理员打开后台时执行脚本。
参考资料
- RFC 9110: HTTP Semantics · IETF
- Cloudflare SSL/TLS Documentation · Cloudflare