验证码识别合法吗？法律实际上是怎么说的

无论是美国、英国还是欧盟的法律，都没有把验证码识别列为一项罪名。没有专门针对它的法条，没有哪个案子是围绕它判的，也没有哪个监管机构把这个行为本身当作违法。所以当有人问验证码识别合不合法时，诚实的答案是：这个问题其实问的是别的事，是你拿到访问权限之后做了什么，你事先同意了谁的条款，以及你拿走了什么数据。本文会通过划出这条界线的那些判例，讲清楚这条线到底在哪里。作者是开发者，不是律师，本文也不构成法律意见。

简短的答案，以及它为什么简短

验证码是一道测试，不是一把锁。它只是在问访问者是不是真人，只要通过测试，谁都能过去。它不会验证任何人的身份，不会授予任何权限，也不保护任何秘密。通过验证码，你得到的东西和任何一个匿名访问者本来就有的一模一样。

正是这个区别，让合法性问题总是最后归结到别的问题上去。规避一项保护受版权作品的技术措施，在很多地方本身就是一项罪名，但验证码不是这种技术措施。进入一个不属于你的账户，在几乎所有地方都是犯罪，而验证码也不是登录环节。把这两者都排除之后，剩下的就只是普通的自动化浏览，这是合法的、常见的，也是互联网大部分内容被搜索引擎收录的方式。

服务条款是一份合同，不是一部刑法

大多数网站的条款里都会在某处禁止自动化访问。违反这个约定是合同层面的问题，会让你被封禁，也可能被网站起诉。但这本身并不会让你变成罪犯，美国的两个判例把这一点讲得越来越清楚。

Van Buren v. United States 一案，2021 年判决， 对 Computer Fraud and Abuse Act 作出了从严限缩的解释：超越授权访问，指的是进入系统里对你关闭的那部分，而不是滥用你本来就有权看到的信息。违反一项关于数据使用方式的政策，跟入侵是两回事。

hiQ Labs v. LinkedIn 一案在 Ninth Circuit（第九巡回法院）走的是同一个方向，法院认定：抓取一个网站向全世界公开发布的数据，不太可能构成未经授权的访问，因为本来就没有任何东西被限制过。这个案子也是故事里带警示意味的另一半：hiQ 在计算机犯罪这一点上打赢了，后来却在违约诉讼上败诉，最终在法院禁令下和解收场。抓取本身不是犯罪，但它违反的那份协议，照样有约束力。

所以真正有用的判断标准，不是有没有一道验证码挡在路上，而是内容是不是公开的，以及你拿走它之前有没有先接受过一份协议。我们自己的 服务条款 也是从另一个角度讲同一件事：这个工具的授权用途是合法用途，至于目标网站那边的责任，由做自动化的那个人来承担。

真正重要的那条界线：公开页面，还是受限账户

有一个问题几乎能把每一个安全的场景和每一个有风险的场景区分开：验证码挡在前面的，是谁都能看到的东西，还是一个账户？

场景	挑战守护的是什么	风险状况
一个藏在反机器人检测后面的公开商品列表页	没有任何私密内容，谁都能通过	最多只是合同风险
你自己的预发布或测试环境	你自己的系统，你自己的许可	无
你自己拥有的一个表单，被一个端到端测试反复操作	同样是你自己的系统	无
登录页、付费墙，或者一个你没有账户的会员专区	一道身份验证边界	有可能构成犯罪
批量注册账户，或撞库攻击	身份信息和他人的数据	在大多数地方都是犯罪
抢票速度超出排队规则允许的范围	美国的一项联邦法规	明确违法

最后这一行，值得单独说一说。 The Better Online Ticket Sales Act of 2016 在美国明确规定：为了买到超出规则允许数量的门票，而规避售票网站上的安全措施或访问控制系统，属于违法行为。这是最接近“有一部法律专门针对破解反机器人检测”的说法，但它的适用范围是特意收窄的，针对的是票务这件事本身，而不是这项技术。

在美国以外

整体结构相似，只是用词换了。英国的 Computer Misuse Act 1990 关注的是对计算机的未经授权访问，这同样指向账户，而不是验证码这类挑战。欧盟成员国落实关于打击信息系统攻击的指令时，核心思路也是一样的。在这些法律里，验证码从来都不是起决定作用的那个事实。

真正跨越这些法律体系、到处都适用的，是数据保护。如果你采集的页面包含个人数据，不管你是怎么拿到它的，GDPR 都会适用于你收集到的内容，反机器人检测从来都不是决定这件事合法与否的因素。欧盟和英国的数据库权利，还带来了另一个独立的问题：你有没有提取了一个结构化数据集合里的实质性部分。这两点都比挡在前面的那道验证码更值得你花心思。

没人会争议的那些用法

很多验证码识别场景根本没有争议，而这也是我们大部分用户在做的事：

• 测试你自己的表单，因为一套连自家注册页面都过不去的端到端测试，本身就有一个漏洞
• 监控你自己运营的网站，一项合成监测要走完和真实用户一样的完整流程
• 无障碍访问场景中，图片或音频挑战对某些人来说是一道障碍，而不是一道测试；替自己解决它，是这种验证码形式逼出来的变通办法，而不是一个漏洞
• 经过授权的安全工作，范围文档里已经写明了你可以接触哪些系统
• 对公开资料做研究和存档，遵循发布者设定的各项条款

无障碍访问这一点，不是坊间传说。W3C 在长达二十年的多次修订中，一直记录着这个问题，具体见 它关于验证码无障碍问题的工作组说明，而音频替代方案也从来没能让所有人都用得上。

这些也正是不限量识别工具改变的是工程实现、而不是合法性的场景：一套会重试的测试，只有在重试免费的情况下才合理。各种方案之间实际的取舍，写在 我们对各家验证码识别服务的对比.

本地运行真正改变你处境的地方

这部分是一个合规问题，而不是一个刑事问题，但常常被人跳过。

云端识别 API 的工作方式，是先接收你的数据。根据挑战类型不同，这可能包括页面 URL、sitekey、表单截图、user agent，有时还有会话信息。你把这些发给了一个第三方，往往在另一个国家，很多时候还会有真人来查看。在 GDPR 下，这构成一种处理者关系，很可能还涉及跨境传输，需要有合同、合法依据和记录。人工识别打码平台还带来第二个问题：那些实际干活的人。

跑在你自己机器上的识别工具，完全没有这些问题。页面数据从不离开你的基础设施，所以没有传输，没有处理者，数据地图里也没有什么需要披露的。服务器模式同样如此：把识别工具指向你的网络或公网 IP，让 VPS 或 CI 运行器可以访问它，只是把这个进程挪到了另一台你自己拥有的机器上，而 连接设置 涵盖了这两种模式。这仍然是你自己的硬件，所以数据依然不会离开你自己的范围。

常见问题

违反一个网站的服务条款，会让我变成罪犯吗？

一般来说不会，至少在 Van Buren 判决之后的美国是这样。它只会让你成为违反了一份协议的一方，这会让你面临被封禁或被起诉的风险，而不是被刑事指控。但这仍然是一个真实的风险，也是大多数抓取纠纷实际争的那个点，所以在针对一个网站开发之前就该读一读它的条款，而不是等出了事再读。

在我自己的网站上识别验证码，是被允许的吗？

是的，没有任何限制条件。系统是你的，规则是你定的，一个走完你自己注册流程的自动化测试，和其他任何测试在性质上并无不同。如果这个小组件是你自己的，在预发布环境里用一个功能开关把它关掉，通常还更简单。只有当预发布必须和生产环境完全一致，或者验证码这条路径本身就是被测对象时，才需要真的去识别它。

如果有验证码挡在前面，抓取公开数据还合法吗？

决定这件事的从来不是验证码。法院看的是数据是不是公开的、你有没有同意条款，在这些代表性判例里，反机器人检测从来都不是起决定作用的事实。个人数据会单独把 GDPR 牵扯进来，版权或数据库权利也可能适用于内容本身。要回答的，是这三个问题。

你们会监控客户用它识别了什么吗？

不会，也没办法，这是产品设计本身带来的直接结果。识别工具跑在你自己的机器上，什么都不会回传，所以我们这边根本没有任务队列可查。真正划定边界的是授权协议。 我们的常见问题 里说明了这个软件会发送什么、不会发送什么。

简短版结论

没有哪部法律给这个行为专门定了名字。真正该问的是三个问题：内容是不是公开的，你有没有接受过协议，你收集到的内容里有没有个人数据。这三点才决定结果，而挡在路上的那道验证码，一个都改变不了。

技术选择真正起作用的地方，是披露问题：云服务是一个接收你数据的第三方，而你自己的 本地验证码识别工具 则不是。如果你正在针对公开页面搭建自动化， 我们的网络爬虫页面 介绍了能让你站在合规一边的那些模式和礼仪。如果涉及真金白银或者真实的风险敞口，请咨询你所在司法辖区的律师。这篇文章是一张地图，不是法律意见。