reCAPTCHA 那个"点选交通灯"的时代正在收尾。在 Next '26 大会上,Google 正式推出 Cloud Fraud Defense,定位为 reCAPTCHA 的继任产品——不再只盯着"你是不是机器人",而是把视野拉到整条业务链路上:登录、注册、支付,哪里有欺诈风险,哪里就有它的检测逻辑。
从"人机识别"到"欺诈识别"的质变
reCAPTCHA 的核心问题始终是:请求方是人还是机器。这在 2010 年代够用,但今天的攻击者早已不是简单脚本。他们用真实浏览器指纹、租用住宅 IP、甚至雇佣真人批量注册——传统 CAPTCHA 在这类场景下几乎失灵。
Cloud Fraud Defense 把检测目标从"bot vs. human"升级为"legitimate vs. fraudulent"。这意味着:
- 注册阶段:识别批量创建的虚假账号,哪怕每个请求都来自不同 IP 和真实浏览器。
- 登录阶段:发现凭证填充(credential stuffing)和账号接管尝试,而不是只拦自动化脚本。
- 支付阶段:标记交易欺诈,包括盗卡支付和退款滥用。
三个阶段覆盖了在线业务最核心的三条欺诈入口,比单独的 CAPTCHA 验证有效得多。
检测逻辑的广度与深度
根据 Google 发布的信息,Cloud Fraud Defense 的检测范围包括:
| 欺诈类型 | 传统 reCAPTCHA 能力 | Cloud Fraud Defense 能力 |
|---|---|---|
| 自动化 bot 攻击 | ✅ 核心能力 | ✅ 保留并增强 |
| 虚假账号注册 | ❌ 不覆盖 | ✅ 新增 |
| 凭证填充 / 账号接管 | ❌ 不覆盖 | ✅ 新增 |
| 交易欺诈 | ❌ 不覆盖 | ✅ 新增 |
广度之外,深度也变了。reCAPTCHA 主要依赖浏览器端挑战和行为分析;Cloud Fraud Defense 则结合了 Google 全局威胁情报(来自搜索、Gmail、Android 等生态的信号)、设备指纹、行为序列分析,以及与 Google Cloud 其他安全产品的联动。这种跨信号关联是单一 CAPTCHA 产品做不到的。
实践:在业务流程中接入风险评估
Cloud Fraud Defense 的接入方式与 reCAPTCHA Enterprise 类似,通过 API 调用获取风险评估结果,但评估维度更丰富。以下是一个在登录流程中集成风险检测的示例——基于 Google Cloud 反欺诈 API 的典型调用模式构建,具体端点和字段名以官方文档为准,此处展示的是可改造的骨架代码。
import json
import httpx
# 项目配置 — 替换为你的 Google Cloud 项目 ID 和 API Key
PROJECT_ID = "your-gcp-project-id"
API_KEY = "your-api-key"
SITE_KEY = "your-site-key"
FRAUD_DEFENSE_ENDPOINT = (
f"https://frauddefense.googleapis.com/v1/projects/{PROJECT_ID}"
f"/assessments?key={API_KEY}"
)
async def assess_login_risk(session_token: str, user_email: str, client_ip: str) -> dict:
"""
在登录流程中调用 Cloud Fraud Defense 进行风险评估。
session_token: 前端 SDK 生成的会话令牌
user_email: 用户登录邮箱
client_ip: 请求来源 IP(从 X-Forwarded-For 或连接信息提取)
返回: 风险评分与建议动作
"""
payload = {
"event": {
"token": session_token,
"siteKey": SITE_KEY,
"expectedAction": "LOGIN",
"userAgent": "server-side-integration",
"userInfo": {
"accountId": user_email,
},
"clientIp": client_ip,
},
# 指定需要评估的欺诈类型
"assessmentTypes": [
"FRAUD_ACCOUNT_TAKEOVER",
"FRAUD_CREDENTIAL_STUFFING",
],
}
resp = await httpx.post(FRAUD_DEFENSE_ENDPOINT, json=payload, timeout=10)
result = resp.json()
# 解析关键字段 — 字段名以官方文档为准,此处为示意结构
risk_score = result.get("riskAnalysis", {}).get("riskScore", 0) # 0-1 浮点数
reasons = result.get("riskAnalysis", {}).get("reasons", [])
recommended_action = result.get("riskAnalysis", {}).get("recommendedAction", "ALLOW")
return {
"risk_score": risk_score,
"reasons": reasons,
"recommended_action": recommended_action,
}
# ── 在 FastAPI 路由中使用 ──────────────────────────────────
from fastapi import FastAPI, Request, HTTPException
app = FastAPI()
@app.post("/api/login")
async def login(request: Request):
body = await request.json()
email = body["email"]
token = body["fraud_token"] # 前端 Cloud Fraud Defense SDK 生成
client_ip = request.headers.get("X-Forwarded-For", request.client.host)
assessment = await assess_login_risk(token, email, client_ip)
# 根据风险评分决定下一步
if assessment["recommended_action"] == "BLOCK":
raise HTTPException(status_code=403, detail="登录行为异常,已被拦截")
elif assessment["recommended_action"] == "CHALLENGE":
# 返回前端,触发二次验证(MFA / 验证码)
return {"status": "challenge_required", "reasons": assessment["reasons"]}
else:
# 正常通过,继续执行登录逻辑
return {"status": "allowed", "risk_score": assessment["risk_score"]}
改造要点:
FRAUD_DEFENSE_ENDPOINT和字段结构需对照正式 API 文档调整——Google Cloud 新产品发布后文档通常在几周内完善。- 前端需要集成 Cloud Fraud Defense 的 JS SDK,在用户交互时生成
session_token,与 reCAPTCHA Enterprise 的前端集成方式一致。 assessmentTypes可按业务场景替换:注册用FRAUD_FAKE_ACCOUNT,支付用FRAUD_TRANSACTION。
迁移考量与取舍
从 reCAPTCHA 迁移到 Cloud Fraud Defense 不是简单换个 SDK。几个需要提前想清楚的问题:
成本结构变化。 reCAPTCHA Enterprise 按评估次数计费;Cloud Fraud Defense 覆盖范围更广,计费模型可能不同(按评估类型或欺诈检测维度计费),需要对比现有调用量和新产品定价。
前端体验。 reCAPTCHA 的可见挑战(图片点选)对用户体验有直接冲击。Cloud Fraud Defense 更依赖后台信号分析,前端挑战会更少——但这也意味着你需要更信任 Google 的后台判断,减少自己可控的验证环节。
数据合规。 将用户行为信号、设备指纹、IP 等数据发送给 Google 进行风险评估,涉及隐私合规审查。尤其在 GDPR 和中国数据出境法规下,需要评估数据流转路径是否满足本地要求。
迁移节奏。 建议分阶段推进:
- 阶段 1:在注册和登录流程中并行接入 Cloud Fraud Defense,与现有 reCAPTCHA 共存,对比两者的检测准确率和误报率。
- 阶段 2:在支付流程中单独启用 Cloud Fraud Defense 的交易欺诈检测——这是 reCAPTCHA 从未覆盖的领域,风险增量可控。
- 阶段 3:数据对比充分后,逐步关闭 reCAPTCHA,完全切换到 Cloud Fraud Defense。
reCAPTCHA 解决的是"门口查身份证"的问题;Cloud Fraud Defense 要做的是"整栋楼的安全监控"。后者能力更强,但接入复杂度和责任边界也更大——值得做,但别一步跳过去。