全部功能
验证

三层防御,四个面,没有机器人能赢

验证是 Caputchin 的核心。各道关卡协同工作;各个面则是你把它们接入自己技术栈的方式。默认路径是小组件加上你后端发起的一次 verify 调用。当默认方式不合适时,其余的面就派上用场。

一次验证如何流转。

访客打开你的页面。小组件运行各道关卡。一枚带签名的令牌越过去交给你的后端。你的后端再请我们确认它。

  1. 访客打开你的页面
  2. Caputchin 小组件在你的页面里加载
  3. 游戏式反作弊在沙箱隔离的 iframe 里运行
  4. 你的后端收到包装好的令牌
  5. /siteverifyCaputchin 确认这枚令牌
无论你是发布小组件、直接调用 API,还是使用托管验证,形态都一样。从访客浏览器跨到你后端的,只有那枚包装好的令牌。
威胁矩阵
所有方案

每一层都为不同的攻击抬高成本。

没有哪一层是要独自击退所有攻击的。重点在于组合:等一个请求抵达游戏时,它已经付清了前面每道关卡的过路费。下面是一张诚实的图。

  • curl 和 fetch 脚本
    光秃秃的 HTTP 脚本,直接打你的端点。
    应对它的层
    • 浏览器探测
  • 无头浏览器
    在后台运行的 Puppeteer、Playwright 或 Selenium。
    应对它的层
    • 浏览器探测
  • 真实浏览器机器人农场
    租用服务器上的真实 Chrome 实例,有时由真人操控。
    应对它的层
    • Proof of work
    • 游戏式反作弊
  • 解题即服务
    付费的解题农场,接下挑战再把答案递回来,往往靠廉价的人力。
    应对它的层
    • Proof of work
    • 游戏式反作弊
  • 前沿 AI 模型
    能读图像网格、解 OCR 谜题、在毫秒间攻破老式 CAPTCHA 的视觉模型和代理模型。
    应对它的层
    • 游戏式反作弊
游戏式反作弊
所有方案

不只是一个游戏。是一台验证引擎。

一个小巧、多变的游戏,真人几秒钟就玩完,还玩得开心。在它底下,跑的是竞技多人游戏抓作弊者用的同一套反作弊打法:我们的服务器在你开玩之前布置好每一局(服务器主导),再在你玩完之后重新模拟一遍(确定性回放),所以这游戏伪造不来,只能老老实实地玩。这是任何其他 CAPTCHA 都没有的一层,也是 Caputchin 存在的理由。

开玩之前

服务器主导的布置

  • 一张带签名的一次性票据(30 分钟窗口)铸出这一局。用过一次,就再也无法重放。
  • 游戏和它的随机种子都在我们服务器上选定,从不在浏览器里,所以客户端那头的任何东西都挑不到更软的柿子。
  • 每次都是池子里不同的一个游戏。解题器永远不知道会碰上哪一个,所以没法提前训练。

和竞技游戏服务器一个模型:客户端只发送输入,从不发送裁决。

玩完之后

确定性回放

  • 你那一份精确的输入,在同一个种子下、在我们服务器上重放,跑在一个无网络、有硬性时间预算的密封 isolate 里。
  • 过没过由那次回放重新算出,从不取自浏览器。
  • 每个游戏的代码在运行前都按哈希核验,所以那份产物没法在你眼皮底下被掉包。

建立在锁步多人游戏所依赖的同一种确定性之上:从种子把这一局重新模拟一遍,确认它真的被玩过。

在你的页面里被沙箱隔离

一个隔离的 iframe,没有网络,也够不着你的 cookie、存储或 DOM。

游戏多样

不同站点拿到不同游戏,目录还在不断变大。

密封回放

回放在无网络、有硬性 CPU 预算的条件下跑。什么都进不来,也出不去。

防篡改代码

每个游戏产物都在第一帧跑起来之前,先按哈希验过。

不做画像

我们不盯着你的鼠标或时序看。我们改为把这一局重新跑一遍。

再叠上两道关卡,并排而立

游戏式反作弊从不单打独斗。一道 proof of work 关卡和浏览器探测与它并行,各自为不同的攻击模式抬高成本。串联组合之下,攻击者每抵达一层,都已经先付了一笔过路费。

所有方案

Proof of work

每一次验证尝试,都迫使访客的浏览器跑一个小小的密码学谜题。真人等上几百毫秒,毫无察觉。而为规模化算力买单的机器人农场,则对每一个周期都感同身受。

适用场景

被自动批量注册盯上的注册表单。每个假账户都让攻击者付出可度量的算力,批量滥用因此贵到不值得一做。

所有方案

浏览器探测

小组件读取访客浏览器暴露出的环境信号。真实浏览器总是有这些信号。无头工具和脚本通常伪装得很差,或者干脆没有。一个按站点的开关“拦截自动化浏览器”,会对探测判定为无头或受驱动控制(Playwright、Selenium、Puppeteer)的一切,一律硬性拒绝。它是选择性开启的,如果你预期会有正当的自动化,就让它保持关闭。

适用场景

被 Playwright 或 Selenium 脚本盯上的评论表单和联系页面。开启拦截自动化浏览器后,脚本会在门口被过滤掉,而不是拿到一道要解的挑战。

集成入口

把验证摆到访客面前的四种方式。挑一个贴合你代码、技术栈或团队形态的。

所有方案

即放即用的 Web 组件

一个 HTML 标签即可挂载小组件。它运行各道关卡,访客通过后便把令牌交给你。在 React、Vue、Svelte、Angular 或纯 HTML 中都能用,因为 Web 组件是浏览器原生的,不需要框架包装层。

适用场景

默认路径。不引入任何新依赖,几分钟就能给你的注册表单加上机器人防护。

所有方案

Runtime API

验证 API 分两部分。一是你的后端在每次集成中都会用到的 verify 调用,用来确认令牌是真的。二是更底层的挑战端点,让你在小组件不适用的少数情况下自行驱动验证。它与你团队用于账户和配置变更的 REST 管理 API 不同。

适用场景

verify 调用:每个后端,始终如此。直接调用 API:聊天、付费墙、织进你自家 UI 的多步表单,以及任何小组件元素无法渲染的地方。

Alpha tier

托管验证

把你表单的 action 指向我们。我们验证访客,再把提交内容转发到你的收件箱或端点。你这边一行后端代码都不用写。

适用场景

没有后端、无法自行验证令牌的静态站点和无代码搭建器。在换掉一个 action 属性的工夫里,就能上线一个带机器人防护的联系表单。

所有方案

移动端 WebView 嵌入

为在自家 WebView 内渲染挑战的 iOS 和 Android 原生应用量身打造的嵌入页面。同一个小组件,更小的体积,不必安装任何原生 SDK。

适用场景

需要验证、却不想下发框架专属 SDK,也不想在每个平台上重建一套原生 CAPTCHA 流程的移动应用。

用一个站点密钥就把验证上线。免费。

注册、铸一个站点密钥、把小组件放到一个表单上。日后需要更高层级的功能时再升级。

免费开始