网络安全应用安全后端【免费下载链接】capFree, open-source and self-hosted CAPTCHA alternative to reCAPTCHA. Privacy-first and powered by proof-of-work and instrumentation challenges.项目地址https://gitcode.com/gh_mirrors/cap13/cap点击查看免费下载导读本文以 Cap免费、开源、自托管的 reCAPTCHA 替代品为对象系统拆解移动端表单场景下的 CAPTCHA 设计问题——为什么图片谜题在手机上伤害最大、移动端友好防护需要满足哪些硬性要求以及 Cap 如何用复选框 Proof-of-Work Instrumentation这套确定性机制实现单次点击完成验证。读完你可以直接照搬表单嵌入、事件监听、难度调节与原生 App API 保护的完整落地路径。为什么 CAPTCHA 在移动端伤害最大移动端是 CAPTCHA 造成转化损失最严重的场景原因有五点官方指南将其归结为图片网格在小屏上不可用。选出所有红绿灯在 6 英寸屏幕上意味着眯眼、缩放和误触桌面端只是烦人的重试循环在移动端直接激怒用户。打断键盘与自动填充。Challenge 在表单中途弹出会收起键盘、中断 Autofill 流程用户丢失输入位置。隐形系统的信号更弱。指纹与行为分析依赖鼠标移动和稳定的网络身份移动端没有鼠标、存在大量运营商级 NAT同一 IP 背后可能上千用户且 Safari 的跟踪防护激进。信号少意味着误判多误判最终变成谜题或封禁。Webview 流量占比巨大。Instagram、TikTok、Gmail 等应用内浏览器承载大量移动流量它们对指纹系统而言看起来可疑。带宽与电量的真实成本。超过 500 KB 的 CAPTCHA 脚本在蜂窝网络下的中端手机上是用户尚未输入任何内容就要付出的代价。这五点构成了移动端防护设计的起点任何依赖分类器打分或图片交互的方案在移动端都有结构性缺陷。移动端友好防护的 5 项硬性要求要在移动端成立机器人防护必须同时满足任何回退条件下都不出现视觉谜题。只要系统有能力下发图片网格移动用户迟早会遇上一次——所以必须从机制上杜绝。人类通行是确定性的。不依赖会因 NAT 运营商 IP 或 Webview 而降分的风险评分。体积小。防护的成本不应超过表单本身。触控优先的 UX。最多一次点击、清晰的进度反馈、不打断键盘。成本可调。解算时长应是运维方手中的旋钮而不是让低端设备干等。Cap 的移动端模型机制设计优于分类器判断Cap 的答案是把低摩擦内建进机制本身一个复选框一次点击背后是浏览器中静默运行的工作量证明Proof-of-Work。它不是靠分类器的裁定来放行人类因此不存在移动端信号弱导致误判这一失败模式。一次点击然后是进度百分比用户点击复选框后Proof-of-Work 在浏览器后台运行一个进度百分比随之填充。没有图片、没有打字、没有键盘收起。在 浮动模式 或 程序化模式 下提交之前界面完全不可见。进度反馈在 widget 源码 中有明确的实现路径解算过程通过dispatchEvent(progress, { progress })派发进度事件前端以约 150 ms 的间隔刷新可视百分比见 cap.js 第 1065 行解算由WorkerPool调度worker 数量默认取navigator.hardwareConcurrency || 8并可通过data-cap-worker-count属性覆盖上限 16见 cap.js 第 495 行 与 cap.js 第 1587 行。进度条的存在不只是视觉反馈它把等待算力转化为可感知的确定性避免用户误以为页面卡死。一个容易被忽略的移动端优化是预解widget 在用户首次交互mousemove/touchstart/keydown后约 2.5 秒即开始预取并后台解算 ChallengeSPECULATIVE_DELAY_MS 2500见 cap.js 第 326 行用户真正点击复选框时往往直接命中已完成的 token。这解释了为什么在移动端反复刷新表单时第二次验证的等待几乎为零。约 20 KB 的单一 Web Component无框架依赖Cap 的 widget 是一个独立的 Web Component不依赖任何前端框架体积约 20 KB在蜂窝网络下加载成本极低。官方 benchmark 页面 给出了各档设备上的实测解算耗时difficulty 4、50 个挑战、WASM 0.0.7档位设备耗时低端Samsung Galaxy A34795 ms低端iPhone SE (2020)798 ms中端Google Pixel 7423 ms高端Google Pixel 9414 ms高端M3 MacBook212 ms注意这些数据使用占位服务器测得实际耗时会随部署与网络延迟变化但量级关系说明移动端的解算差异主要由设备算力而非网络决定。无指纹惩罚Cap 不关心访客是否位于运营商 NAT 之后、是否身处 Instagram Webview、是否开启了 iOS Safari 的跟踪防护——Proof-of-Work 对所有人是同一道计算题。这与 reCAPTCHA v3、Turnstile 这类指纹驱动方案形成根本区别后者在移动端信号稀薄的环境中更容易误判且误判后用户没有任何申诉渠道。难度属于你按站点密钥调节解算成本是运维方可控的旋钮。在 Standalone 服务器 上每个站点密钥都可以独立配置HashWX difficulty客户端需计算的目标哈希数默认1_000_000拆分为 4 个子挑战合法范围50_000–5_000_000见 options.md。文档给出的参照是8 核桌面 Chrome 上默认难度中位耗时 578 ms手机上约 1.1–5.9 s。因此建议消费者结账流量用低难度易被滥用的注册端点用高难度——这是成本可调要求在部署层的直接落地。HashWX 文档 还给出了真实手机上的完整测量BrowserStack 实测每次均从全新加载的页面开始含两轮到测试服务器的往返往返中位 80–190 ms/设备设备系统全核算力中位最慢Galaxy S24Android 141238 KH/s1.1 s1.8 sPixel 9Android 15837 KH/s1.4 s2.0 sPixel 6Android 12746 KH/s1.9 s2.4 siPhone 15iOS 17未测量1.9 s4.3 siPhone 12iOS 17620 KH/s2.0 s3.3 siPhone 13iOS 15678 KH/s2.2 s4.1 siPhone SE 2022iOS 15588 KH/s2.4 s4.0 sRedmi Note 11Android 11456 KH/s2.4 s4.8 sGalaxy M32Android 11444 KH/s2.8 s6.1 sVivo Y21Android 11316 KH/s5.9 s11.0 s预算级 AndroidVivo Y21比 M3 桌面慢约 10 倍。如果主要流量来自移动端就应调低难度——解算时间与难度线性相关500_000大致可以把上表所有解算部分减半。另一个实测结论是页面已运行 HashWX 一分钟后Pixel 6 单次解算耗时降低 24%、Vivo 降低 29%所以预热后跑分会好看得多生产环境应保持冷启动视角。触觉反馈与无障碍细节移动端体验的完成度体现在细节上widget 支持成功后震动反馈navigator.vibrate([10, 50, 20, 30, 40])但会尊重prefers-reduced-motion: reduce并可通过CAP_DISABLE_HAPTICS或data-cap-disable-haptics关闭见 cap.js 第 3 行与第 841 行。触发按钮带rolebutton、tabindex与aria-live属性支持键盘回车与空格触发。这些设计让一次点击不仅对普通用户成立对依赖无障碍辅助的用户也可用。Instrumentation 依旧生效Proof-of-Work 证明的是付出过算力不证明来自真实浏览器。因此 Instrumentation Challenges 作为第二层叠加存在服务器每次下发一段唯一的 JavaScript在沙箱 iframe 中执行真实 DOM 操作与计算链服务端并行跟踪预期结果并核对从而捕获纯 PoW 挡不住的无头自动化——同时不涉及对人类用户的画像。在 cap.js 源码 中可以看到其客户端执行路径对压缩的 instr 字节做 base64 解码与 inflate注入 1px 大小的沙箱 iframe通过postMessage回收结果。一个诚实的权衡必须说明PoW 消耗 CPU 时间低端手机解算慢于桌面。Cap 的缓解手段正是上文的可配置难度 可见进度反馈且工作量按每表单一次计而非每页浏览一次。移动端方案横向对比方案机制移动端表现reCAPTCHA v2 / hCaptcha图片网格 回退移动端最差体验两者都会回退到图片谜题reCAPTCHA 客户端超 500 KB。详见 Cap vs reCAPTCHA 与 Cap vs hCaptchareCAPTCHA v3不可见评分无交互但基于评分NAT、Webview 等弱移动信号会拉低分数且无申诉渠道Turnstile不可见指纹体积小但指纹驱动移动 Safari 隐私特性与 Webview 是已知错误源且无法覆盖其裁定。详见 Cap vs TurnstileFriendlyCaptchaPoW与 Cap 机制同源、移动端机械上可行但托管、按配额计价且只有 PoW。详见 Cap vs FriendlyCaptchaSilentShield行为分析依赖鼠标/键盘/滚动模式触屏设备上这些信号更稀薄且形态不同封闭、按配额计价。详见 Cap vs SilentShield结论是移动端场景下确定性机制PoW相比分类器机制评分/指纹/行为少了一个信号不足导致误判的失败维度。实施要点从 HTML 表单到原生 App API表单内自动注入cap-token把cap-widget放进form内Cap 会自动注入隐藏的cap-token字段并随表单提交无需任何 JavaScript。该行为在源码中可见cap.js 第 969 行 于组件挂载时写入input typehidden namecap-token字段名可通过data-cap-hidden-field-name自定义默认cap-token见 cap.js 第 804 行。完整接入流程服务器启动、密钥创建、token 校验见 快速开始。form action/submit methodPOST !-- 你的表单字段 -- cap-widget>const widget document.querySelector(cap-widget); widget.addEventListener(solve, (e) { const token e.detail.token; // 发送 token 到你的服务器、启用提交按钮等 });需要完全掌控流程时用 程序化模式new Cap({ apiEndpoint })创建实例并调用cap.solve()获取{ token }还可监听progress事件展示自定义进度条。在真实中端 Android 蜂窝网络上测试官方指南明确建议用真实的中端 Android 在蜂窝网络下测试而不是旗舰机连 Wi-Fi根据目标受众把难度调到感觉上是即时的。对照上文手机测量表默认1_000_000难度在低端设备上约 2–6 s若你的受众大量使用这类设备应下调难度。保护原生 App 的 API如果你保护的是原生 App 的 API 而非 Web 表单Cap 的 Standalone 服务器 可以对任何能在 Webview 中执行 Challenge 的客户端验证 token——App 内嵌 Webview 运行 Challenge拿到 token 后随 API 请求提交服务端调用/siteverify校验。验证接口与 reCAPTCHA 的 siteverify API 兼容迁移时只需改一个 URL。常见问题移动端表单最适合用哪种 CAPTCHA一种永远不会显示谜题、永远不会误分类的方案。Cap 的复选框 PoW模型是确定性的、约 20 KB、且为触控而设计。如何阻止移动端表单的垃圾提交用成本而非提问。PoW 让每一次提交对规模化 bot 而言都算力昂贵对人类仍只是一次点击。移动端隐形 CAPTCHA 更好吗只有当它的误判率站得住时才是——而移动端恰恰是指纹与行为信号最弱的场景。确定性机制不存在这种失败模式。Cap 在移动端能用吗可以移动 Safari、Chrome、Firefox 与应用内 Webview 均支持难度可调让慢设备上的解算时间保持短暂。注意 iOS 上需 iOS 15 或更新且无 WebAssembly 的客户端无法解 HashWX此类客户端应切换到带纯 JS 回退的 SHA-256 PoW。哪种 CAPTCHA 的用户摩擦最小无谜题选项包括 Cap、Turnstile、FriendlyCaptcha、ALTCHA、SilentShield。Cap 是其中开源、自托管的一个其低摩擦来自机制设计而非分类器裁定。延伸阅读CAPTCHA 与转化率桌面与移动端的漏斗计算2026 年最佳 CAPTCHA 替代方案全景对比有效性分析为什么成本优于分类HashWX 工作量证明GPU 抗性协议的完整原理与测量Standalone 配置选项难度、CORS、限流、健康检查实时演示在手机上亲自体验赞分享网络安全应用安全后端【免费下载链接】capFree, open-source and self-hosted CAPTCHA alternative to reCAPTCHA. Privacy-first and powered by proof-of-work and instrumentation challenges.项目地址https://gitcode.com/gh_mirrors/cap13/cap点击查看免费下载相关推荐Myrtille终极指南原生HTML远程桌面协议与SSH客户端的完整解析Myrtille终极指南原生HTML远程桌面协议与SSH客户端的完整解析 Myrtille是一款强大的原生HTML4/HTML5远程桌面协议RDP和SSHFront-End-Checklist 安全规则实战为公开表单接入 CAPTCHA 与机器人防护Front End Checklist 安全规则实战为公开表单接入 CAPTCHA 与机器人防护 本指南基于 Front End Checklist 仓库中如何用Guzzle实现SSL证书固定终极中间人攻击防护指南如何用Guzzle实现SSL证书固定终极中间人攻击防护指南 Guzzle作为PHP最流行的HTTP客户端提供了强大的SSL证书验证功能来保护你的应用免受中间后端上一篇终极指南如何使用Prince库轻松完成Python多变量探索性数据分析下一篇React Router 发布说明实战何时以及如何为 release notes 撰写 Whats Changed 长文创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考