Skip to content

Bot Management and Anti-Automation Cheat Sheet / 机器人管理与反自动化技巧清单

Introduction / 介绍

Modern web applications face a continuous stream of automated traffic that is not a Distributed Denial of Service event but is still abusive: credential stuffing, content scraping, inventory hoarding (scalping), fake account creation, gift-card enumeration, card testing, fake reviews, click fraud, and skewed analytics. The OWASP Automated Threats to Web Applications project (OAT-001 through OAT-021) catalogs these patterns.

现代网络应用面临持续不断的自动化流量,这并非分布式拒绝服务事件,但仍属滥用行为:凭证填充、内容抓取、库存囤积(炒票)、虚假账户创建、礼品卡枚举、卡片测试、虚假评论、点击欺诈和扭曲分析。OWASP 网络应用自动化威胁 项目(OAT-001至OAT-021)对这些模式进行了分类。

This cheat sheet provides defensive guidance that goes beyond the Credential Stuffing Prevention Cheat Sheet and addresses the full spectrum of automated abuse. It focuses on architecture, signals, response strategy, and CAPTCHA alternatives.

这份技巧清单提供了超越凭证填充预防技巧清单的防御性指导,并针对自动化滥用的全面范围。它侧重于架构、信号、响应策略和CAPTCHA替代方案。

The objective is not to block all bots (search engine crawlers, monitoring agents, and accessibility tools are legitimate) but to raise the cost of abusive automation while keeping legitimate users and bots unaffected.

目标是不是阻止所有机器人(搜索引擎爬虫、监控代理和辅助工具是合法的),而是提高滥用自动化的成本,同时保持合法用户和机器人不受影响。

Common Threats and Risks / 常见威胁和风险

  • OAT-008 Credential Stuffing — replaying breached username/password pairs.
    中文:OAT-008 凭证填充 — 重放已泄露的用户名/密码对。
  • OAT-011 Scraping — large-scale content, price, or PII extraction.
    中文:OAT-011 抓取 — 大规模内容、价格或PII提取。
  • OAT-005 Scalping / Inventory Hoarding — buying limited stock for resale.
    中文:OAT-005 撮取/库存囤积 — 购买限量库存进行转售。
  • OAT-019 Account Creation — fake accounts at signup endpoints.
    中文:OAT-019 账户创建 — 在注册端点创建虚假账户。
  • OAT-012 Cashing Out — using stolen accounts to extract value.
    中文:OAT-012 提现 — 使用被盗账户提取价值。
  • OAT-001 Carding — testing stolen card numbers via low-value purchases.
    中文:OAT-001 信用卡欺诈 — 通过小额购买测试被盗的卡号。
  • OAT-003 Ad Fraud — fake clicks and impressions.
    中文:OAT-003 广告欺诈 — 假点击和假曝光。
  • OAT-002 Token Cracking — brute-forcing gift cards, vouchers, coupons.
    中文:OAT-002 令牌破解 — 强制破解礼品卡、优惠券。
  • OAT-015 Denial of Inventory — adding items to cart to deplete stock.
    中文:OAT-015 库存拒绝服务 — 将商品添加到购物车以耗尽库存。
  • OAT-014 Vulnerability Scanning — automated probing for weaknesses.
    中文:OAT-014 漏洞扫描 — 自动探测弱点。
  • Skewed business metrics — bots polluting A/B tests, recommendations, fraud models.
    中文:业务指标偏差 — 机器人污染 A/B 测试、推荐、欺诈模型。
  • Privacy violations — over-collecting fingerprinting data to defend against bots.
    中文:隐私侵犯 — 过度收集指纹数据以防御机器人。

Threat Modeling Before Controls / 在控制之前进行威胁建模

Before adding tooling, identify which OAT categories apply to your application and which endpoints are at risk. A login form, a search page, a checkout, and a public API have very different threat profiles and defenses.

在添加工具之前,确定哪些OAT类别适用于您的应用程序以及哪些端点是受风险的。登录表单、搜索页面、结账和公共API具有非常不同的威胁特征和防御措施。

Endpoint type / 端点类型 Primary OAT risk / 主要 OAT 风险 Suggested first control / 建议的首要控制
Login
登录
OAT-008 Credential Stuffing
OAT-008 凭证填充
Rate limit + breached-password check + MFA
速率限制 + 破坏密码检查 + 多因素认证
Signup
注册
OAT-019 Account Creation
OAT-019 账户创建
Email/phone verification + velocity limits
电子邮件/电话验证 + 速度限制
Search / catalog
搜索 / 目录
OAT-011 Scraping
OAT-011 爬虫
Rate limit per identity + behavioral signal
每个身份的速率限制 + 行为信号
Checkout / cart
结账 / 购物车
OAT-005 Scalping, OAT-001 Carding Queue + purchase limits + 3D Secure
队列 + 购买限制 + 3D Secure
Public API
公共API
OAT-011, OAT-014 API keys + per-key quotas + signed requests
API密钥 + 每个密钥配额 + 签名请求
Comments / reviews
评论 / 评论
OAT-020 Account Aggregation, spam
OAT-020 账户聚合,垃圾邮件
Reputation + delayed publishing
声誉 + 延迟发布

Layered Defense Architecture / 分层防御架构

A single control is brittle. Combine controls at three layers:

单一控制措施是脆弱的。在三个层次上组合控制措施:

  1. Edge layer — CDN, WAF, or anti-bot service: IP reputation, ASN filtering, TLS fingerprint (JA3/JA4), HTTP/2 fingerprint, basic rate limits.
    中文:边缘层 — CDN、WAF 或反机器人服务:IP 声誉、ASN 过滤、TLS 指纹(JA3/JA4)、HTTP/2 指纹、基本速率限制。
  2. Application layer — session-aware rate limits, identity-bound quotas, behavioral signals, honeypots, CAPTCHA challenges.
    中文:应用层 — 会话感知的速率限制,身份绑定配额,行为信号,诱饵,CAPTCHA 挑战。
  3. Backend / business layer — anomaly detection on transactions, account-velocity rules, fraud scoring, async review queues.
    中文:后端/业务层 — 交易异常检测、账户速度规则、欺诈评分、异步审查队列。

A request that looks human at one layer (good IP, valid CAPTCHA) may still fail at another (10 checkouts in 30 seconds with different cards).

在某一层看起来像人类请求(良好的 IP,有效的 CAPTCHA)可能在另一层仍然失败(30秒内使用不同卡片进行10次结账)。

Rate Limiting and Quotas / 速率限制和配额

Rate limiting is the foundational control. Apply it at multiple keys, not just IP.

速率限制是基础控制措施。在多个键上应用它,而不仅仅是 IP。

  • Per IP — coarse, defeated by residential proxy networks but still useful as a floor.
    中文:按 IP — 粗略的,被住宅代理网络击败,但仍然作为基础有用。
  • Per session / cookie — defeated by cookie clearing, useful against unsophisticated bots.
    中文:会话/cookie — 可被清除cookie击败,对抗简单机器人有效。
  • Per authenticated identity — most reliable; applies after login.
    中文:每个认证身份 — 最可靠的;在登录后应用。
  • Per endpoint — the login endpoint deserves a tighter limit than the home page.
    中文:每个端点 — 登录端点应比主页有更严格的限制。
  • Per ASN or geo — useful when traffic from datacenter ASNs is unexpected.
    中文:每个 ASN 或地理位置 — 当数据中心 ASN 的流量意外时很有用。

Use a token-bucket or sliding-window algorithm. Avoid fixed-window counters: they allow bursts at boundary times.

使用令牌桶或滑动窗口算法。避免使用固定窗口计数器:它们允许在边界时间发生突发。

A correct login-endpoint rate limit applies two independent buckets, both of which must be under their threshold for the request to pass:

正确的登录端点速率限制应用两个独立的桶,两个桶都必须低于其阈值才能通过请求:

  • Per-username bucket — limits attempts against any single account regardless of source IP. Defends a targeted account from a distributed attack.
    中文:按用户名桶 — 限制针对任何单个账户的尝试,无论来源 IP 地址。防御分布式攻击针对的目标账户。
  • Per-IP (or per-IP+ASN) bucket — limits the volume of attempts originating from one source against any account. Defends against credential-stuffing sweeps that try one password per account.
    中文:按 IP(或按 IP+ASN)桶 — 限制来自一个来源针对任何账户的尝试量。防御尝试每个账户使用一个密码的凭证填充扫描。

A common mistake is to use a single bucket keyed on the combination of IP and username (e.g., login:<ip>:<user>). This creates one bucket per pair, which means a single IP can attempt the threshold against an unlimited number of usernames before any limit fires — exactly the credential-stuffing pattern you were trying to stop. Always check the two buckets separately.

一个常见的错误是使用一个基于 IP 和用户名 组合 的单个桶(例如,login:<ip>:<user>)。这意味着每个组合对应一个桶,这意味着单个 IP 可以在触发任何限制之前尝试无限数量的用户名,这正好是你试图阻止的凭证填充模式。始终单独检查两个桶。

When a limit is hit, return a generic 429 Too Many Requests. Avoid Retry-After values precise enough to schedule retries against. Do not include diagnostic detail (which bucket fired, remaining attempts) — that information is useful only to attackers tuning their tooling.

当达到限制时,返回通用的 429 Too Many Requests。避免提供足够精确的 Retry-After 值以便于调度重试。不要包含诊断细节(哪个桶触发,剩余尝试次数)——这些信息仅对调整工具的攻击者有用。

Device and Network Fingerprinting (Privacy-Aware) / 设备和网络指纹识别(隐私感知)

Fingerprinting helps detect bots that rotate IPs but reuse client environments. Use passive, network-level signals first; resort to client-side fingerprinting only when necessary.

指纹识别有助于检测那些旋转 IP 但重用客户端环境的机器人。首先使用 被动、网络级别 的信号;仅在必要时才求助于客户端指纹识别。

Network signals (no client cooperation needed):

网络信号(无需客户端合作):

  • JA3 / JA4 — TLS ClientHello fingerprint. Headless tooling often produces uncommon JA3 values.
    中文:JA3 / JA4 — TLS ClientHello 指纹。无头工具通常会产生不常见的JA3值。
  • HTTP/2 fingerprint (Akamai) — frame ordering, settings, priorities.
    中文:HTTP/2 指纹(Akamai) — 帧排序、设置、优先级。
  • Client Hints (Sec-CH-UA-*) — declared but verifiable against TLS fingerprint.
    中文:客户端提示(Sec-CH-UA-*) —— 已声明且可通过 TLS 指纹验证。

Browser-side signals (last resort, with consent where required):

浏览器端信号(最后手段,在需要时获得同意):

  • WebGL renderer string, canvas hash, font list, audio context — strong but invasive.
    中文:WebGL 渲染器字符串、画布哈希、字体列表、音频上下文 —— 强有力但侵入性大。
  • Page-level behavioral telemetry (mouse paths, scroll, focus) — collect only on sensitive flows.
    中文:页面级行为遥测(鼠标路径、滚动、焦点)——仅在敏感流程中收集。

Privacy guidance:

隐私指南:

  • Document fingerprinting in your privacy notice; some jurisdictions (EU/UK ePrivacy, CCPA) require disclosure or opt-out.
    中文:在您的隐私通知中记录文档指纹;某些司法管辖区(欧盟/英国ePrivacy、CCPA)要求披露或选择退出。
  • Hash or truncate any fingerprint before storage; do not retain raw values that enable re-identification.
    中文:在存储前对任何指纹进行哈希或截断;不要保留能够实现重新识别的原始值。
  • Set short retention windows (hours to days) for anti-bot signals — long enough to detect, short enough to limit surveillance risk.
    中文:为反机器人信号设置较短的保留窗口(几小时到几天)——足够检测,但不足以限制监控风险。
  • Avoid fingerprinting authenticated, low-risk traffic (a logged-in user reading their own profile does not need to be fingerprinted again).
    中文:避免对已认证的低风险流量进行指纹识别(登录用户阅读自己的个人资料不需要再次指纹识别)。

CAPTCHA and Its Modern Alternatives / CAPTCHA及其现代替代品

Visible CAPTCHAs (image grids, distorted text) are accessibility-hostile, machine-solvable by ML, and outsourced to human solver farms for fractions of a cent per solve. Treat them as a last-resort step-up, not a primary defense.

可见的CAPTCHA(图像网格、扭曲文本)对可访问性有害,可以通过机器学习解决,并且以每解决一次几分钱的价格外包给人工解决农场。将它们视为最后的补充步骤,而不是主要防御手段。

Prefer the following alternatives or layer them:

优先考虑以下替代方案或分层使用:

  • Cryptographic attestation tokens — Privacy Pass lets an origin verify that a client satisfied an issuer's attestation policy, such as a CAPTCHA, a device check, or account validation. Select trusted issuers whose policies match your use case; a valid token is not a general proof that the requester is human. Privacy guarantees depend on the deployment and its trust assumptions.
    中文:加密证明令牌 — Privacy Pass 允许源验证客户端是否满足发行者的证明策略,例如 CAPTCHA、设备检查或账户验证。选择与您的用例相匹配的受信任发行者;有效的令牌并不能证明请求者是人类。隐私保证取决于部署及其信任假设。
  • Managed challenges — Cloudflare Turnstile returns a validation result, not a risk score. Validate each token server-side with Siteverify, require success: true, and check the expected hostname and configured action. Tokens expire after five minutes and are single-use.
    中文:管理挑战 — Cloudflare Turnstile 返回验证结果,而不是风险评分。在服务器端使用 Siteverify 验证每个令牌,要求 success: true,并检查预期的主机名和配置的操作。令牌在五分钟后过期,且只能使用一次。
  • Invisible risk scoring — reCAPTCHA v3 and hCaptcha Enterprise return scores for application-defined thresholds.
    中文:不可见风险评分 — reCAPTCHA v3和hCaptcha Enterprise为应用程序定义的阈值返回分数。
  • Proof of work (PoW) — require computation before serving selected expensive requests. This can increase automation cost but does not establish that the client is human. Benchmark supported clients: overly hard puzzles can themselves deny service to legitimate users.
    中文:工作量证明 (PoW) — 在服务选定的昂贵请求之前需要计算。这可能会增加自动化成本,但并不能证明客户端是人类。支持的基准客户端:过于困难的谜题本身可能会拒绝合法用户的请求。
  • WebAuthn / Passkeys — for high-value flows, possession of a registered authenticator is a far stronger bot signal than any CAPTCHA.
    中文:WebAuthn / Passkeys — 对于高价值流程,拥有已注册的验证器的占有比任何 CAPTCHA 都能更强烈地表明是机器人。

Use a maintained challenge implementation rather than a standalone hash check. Keep the challenge, difficulty and expiry under server control; reject unknown, expired or spent challenges, and prevent concurrent reuse. Bind the accepted work to the intended policy. The Anubis challenge lifecycle illustrates validation and reuse checks beyond the hash itself. Retain rate limits after a challenge is passed.

使用维护的挑战实现而非独立的哈希检查。将挑战、难度和过期时间控制在服务器端;拒绝未知、过期或耗尽的挑战,并防止并发重用。将接受的工作绑定到预期策略。Anubis挑战生命周期Anubis challenge lifecycle说明了除了哈希本身之外,还进行了验证和重用检查。通过挑战后保留速率限制。

Honeypots and Tarpits / 蜜罐和陷阱

Cheap, effective, and zero impact on legitimate users.

成本低、效果显著,对合法用户无影响。

  • Hidden form fields — a <input type="text" name="website" /> styled display:none and labeled "leave blank." Bots fill it; humans do not. Reject the submission.
    中文:隐藏表单字段 — <input type="text" name="website" /> 样式的 display:none 并标记为 "留空"。机器人会填写它;人类不会。拒绝提交。
  • Robots.txt traps — disallow a bait path in robots.txt; treat any traffic to it as malicious (well-behaved crawlers respect the directive; abusive ones do not).
    中文:robots.txt陷阱 — 在robots.txt中禁止诱饵路径;将该路径上的任何流量视为恶意(行为良好的爬虫会尊重此指令;滥用者则不会)。
  • Tarpitting — for detected bots, do not return 403. Slow responses progressively (e.g., setTimeout(send, 5000 + jitter)). The bot's throughput collapses without telegraphing detection.
    中文:陷阱 — 对于检测到的机器人,不要返回403。逐步减慢响应速度(例如,setTimeout(send, 5000 + jitter))。机器人的吞吐量会下降,而不会泄露检测信息。
  • Canary content — embed unique, watermarked records on listing pages. If they appear elsewhere, you have proof of scraping and a fingerprint of the scraper.
    中文:金丝雀内容 — 在列表页面上嵌入独特、带水印的记录。如果它们出现在其他地方,你就有证据证明发生了抓取,并且有爬虫的指纹。
<!-- Honeypot field. Real users never see or fill this. -->
<div aria-hidden="true" style="position:absolute;left:-10000px;top:auto;width:1px;height:1px;overflow:hidden;">
  <label for="company_url">Leave this field empty</label>
  <input type="text" id="company_url" name="company_url" tabindex="-1" autocomplete="off" />
</div>

Server side: if company_url is non-empty, silently drop the request or route to a tarpit.

服务器端:如果company_url不为空,则静默丢弃请求或路由到陷阱。

Defending Specific Flows / 防御特定流量

Account creation (OAT-019) / 账户创建(OAT-019)

  • Verify email before the account is usable; do not just send a confirmation, gate features behind it.
    中文:在账户可用之前验证电子邮件;不要仅仅发送确认,将功能置于其后。
  • Check email against disposable-domain lists (refresh weekly).
    中文:将电子邮件与一次性域名列表进行核对(每周刷新)。
  • For phone verification, check the carrier type — VoIP numbers are abundant and cheap.
    中文:对于电话验证,检查运营商类型——VoIP号码丰富且价格低廉。
  • Apply a per-IP, per-ASN, per-device-fingerprint signup velocity limit (e.g., 3 per hour).
    中文:应用每个IP、每个ASN、每个设备指纹的注册速度限制(例如,每小时3个)。
  • Reject signup if the email's local-part has high entropy and recent-creation domain.
    中文:如果电子邮件的本地部分具有高熵和近期创建的域名,则拒绝注册。

Login (OAT-008) / 登录(OAT-008)

  • Apply per-username and per-IP limits with separate windows.
    中文:应用每个用户名和每个IP的限制,并使用独立的窗口。
  • Check the submitted password against breach corpora (e.g., HaveIBeenPwned k-Anonymity API) — do not block, but require a step-up.
    中文:检查提交的密码是否与泄露数据库(例如,HaveIBeenPwned k-Anonymity API)匹配——不要阻止,但要求进行升级步骤。参见身份验证和多因素认证速查表以获取实施指南。
  • On suspicious patterns, require MFA even for low-risk users. See the Authentication and Multifactor Authentication cheat sheets for implementation guidance.
    中文:对于可疑模式,即使是低风险用户也要求进行多因素认证。参见身份验证和多因素认证速查表以获取实施指南。
  • See the Credential Stuffing Prevention Cheat Sheet for full guidance.
    中文:参见凭证填充预防速查表以获取完整指导。

Inventory / scalping (OAT-005, OAT-015)

  • Waiting room / virtual queue for limited drops — randomized admission, tokens bound to session and identity.
    中文:等待室/虚拟队列 用于限量发布 — 随机准入,令牌绑定到会话和身份。
  • Per-account purchase limits enforced server side, including identity proxies (same payment method, same shipping address, same device).
    中文:按账户购买限制在服务器端执行,包括身份代理(相同的支付方式、相同的收货地址、相同的设备)。
  • Hold time — inventory in cart must be paid for within N seconds or released; prevents cart-camping.
    中文:持有时间——购物车中的库存必须在N秒内付款或释放;防止购物车露营。
  • Address and payment dedup at order time using normalized hashes (street + zip, BIN + last4 + holder hash).
    中文:在订单时使用归一化哈希(街道+邮编,BIN+最后4位+持卡人哈希)进行地址和支付去重。

Public APIs / 公共API

  • API keys with rotating secrets, not static bearer tokens checked in to client code.
    中文:带有旋转密钥的API密钥,不是静态的bearer令牌在客户端代码中检查。
  • Per-key quotas advertised in X-RateLimit-* headers so well-behaved clients self-throttle.
  • Request signing (e.g., HMAC of method + path + timestamp + body) to prevent replay and require a stable secret.
  • Tier APIs explicitly: a public catalog endpoint may serve cached, slightly-delayed data; partner APIs serve realtime data with an authenticated key.

Response Strategy: Don't Always Block

Hard blocks teach attackers what worked. A graduated response is more durable.

Confidence / 信心 Response / 响应
Low (suspicious)
低(可疑)
Log; serve normally; flag the session
日志;正常服务;标记会话
Medium
中等
Step-up: CAPTCHA, MFA, or PoW challenge
提升:验证码、多因素认证或工作量证明挑战
High Tarpit (slow responses), serve stale or randomized data
陷阱(慢响应),提供陈旧或随机数据
Very high
非常高
Soft-block specific actions (e.g., disable checkout, allow browsing)
软阻止特定操作(例如,禁用结账,允许浏览)
Confirmed abuse
确认滥用
Account hold + manual review; do not delete to allow forensics
账户冻结 + 手动审查;不要删除以允许取证

For scrapers specifically, returning plausible but slightly wrong data (price ±1%, fake stock counts) poisons the dataset and is often more damaging to the business case for scraping than a 403.

Logging and Monitoring / 记录和监控

Bot incidents are detected post-hoc almost as often as in real time. Log enough to investigate.

For each request to a sensitive endpoint, capture:

  • Timestamp, request ID, route, status code.
  • Client IP, ASN, country.
  • TLS fingerprint (JA3/JA4) and HTTP/2 fingerprint.
    中文:TLS指纹(JA3/JA4)和HTTP/2指纹。
  • User-Agent (raw, plus parsed family/version).
    中文:用户代理(原始,包括解析后的家族/版本)。
  • Authenticated identity (or session ID hash).
  • Decision and signals (e.g., bot_score=0.87, rule=login_velocity).

Mask credentials and PII in logs (see the Logging Cheat Sheet.

Build dashboards for: requests-per-second by endpoint, 4xx/5xx rate, fail rate by route, signup-to-purchase funnel, login success rate. Sudden shifts (more than 3-sigma) on these are bot signals.

# Minimal structured log record for an anti-bot decision.
import json, hashlib, time

def log_decision(req, score, decision, rule):
    record = {
        "ts": int(time.time() * 1000),
        "route": req.path,
        "ip": req.remote_addr,
        "asn": req.headers.get("X-ASN"),  # set by your edge
        "ja4": req.headers.get("X-TLS-JA4"),
        "ua": req.headers.get("User-Agent"),
        "session": hashlib.sha256(
            (req.cookies.get("sid") or "").encode()
        ).hexdigest()[:16],
        "score": score,
        "decision": decision,   # allow | challenge | tarpit | block
        "rule": rule,
    }
    print(json.dumps(record))

Privacy and Compliance

Anti-bot defenses collect data. Treat them like any other data-processing activity.

反机器人防御收集数据。将其视为任何其他数据处理活动。

  • Document the applicable lawful basis and the categories of data collected. Assess any consent requirements or exemptions for device storage and access, including fingerprinting; UK ICO guidance explains that legitimate interests cannot replace consent when consent is required.
    中文:记录适用的法律依据和数据收集的分类。评估设备存储和访问的同意要求或豁免,包括指纹;英国信息专员办公室指导 解释说,在需要同意的情况下,合法利益不能取代同意。
  • Apply data minimization: collect what you need to score the request and discard the rest.
    中文:应用数据最小化:收集评分请求所需的数据,丢弃其余数据。
  • Set a short retention period for raw signals; aggregate for longer-term analytics.
    中文:为原始信号设置较短的保留期;进行长期分析时进行聚合。
  • If you use a third-party anti-bot vendor, list them as a sub-processor and review their DPIA.
    中文:如果您使用第三方反机器人供应商,将其列为子处理器并审查其DPIA。
  • Do not block users solely because their browser is hardened (privacy-respecting users often look "bot-like"). Prefer challenge to block.
    中文:不要仅因为用户的浏览器加固(尊重隐私的用户通常看起来像机器人)而阻止用户。优先选择挑战而非阻止。
  • Provide an accessible alternative when challenging users with CAPTCHAs (audio CAPTCHA, support contact).
    中文:当对用户进行CAPTCHA挑战时提供可访问的替代方案(音频CAPTCHA,支持联系)。

Anti-Patterns to Avoid / 要避免的反模式

  • Blocking all traffic with non-standard User-Agents — breaks legitimate research, accessibility, and integration tools.
    中文:使用非标准User-Agent阻止所有流量——破坏合法研究、可访问性和集成工具。
  • Relying solely on a single edge vendor "magic box" — when it tunes wrong, your entire site goes down or opens up.
    中文:仅依赖单一边缘供应商的“魔法盒子”——一旦调校错误,整个网站就会宕机或被打开。
  • Storing raw fingerprints indefinitely.
    中文:无限期存储原始指纹。
  • CAPTCHAs at every login attempt — destroys conversion and trains users to solve mechanically.
    中文:每次登录尝试都使用CAPTCHA——破坏转化并训练用户机械地解决问题。
  • "Hidden" anti-bot rules with no logging — you cannot tune what you cannot see.
    中文:没有日志记录的“隐藏”反机器人规则——你无法调整你看不见的东西。
  • Hard-blocking on first signal, with no graduated response — gives attackers a clean signal to iterate against.
    中文:在第一次信号时硬性阻止,没有逐步响应——给攻击者一个干净的信号来迭代。

Checklist / 清单

  • Map application endpoints to the OWASP Automated Threats (OAT) catalog.
    中文:[ ] 将应用程序端点映射到OWASP自动化威胁(OAT)目录。
  • Apply rate limits at IP, identity, and endpoint levels, using a sliding window.
    中文:[ ] 在IP、身份和端点级别应用速率限制,使用滑动窗口。
  • Layer defenses across edge, application, and business logic.
    中文:[ ] 在边缘、应用和业务逻辑层建立防御层。
  • Use TLS/HTTP-level fingerprints before resorting to browser fingerprinting.
    中文:[ ] 在求助于浏览器指纹之前,先使用TLS/HTTP级别的指纹。
  • Replace visible CAPTCHAs with attestation tokens, invisible scoring, or PoW where possible.
    中文:[ ] 在可能的情况下,用证明令牌、不可见评分或工作量证明(PoW)替换可见的CAPTCHA。
  • Add honeypot fields and tarpit responses for high-confidence detections.
    中文:[ ] 添加诱饵字段和陷阱响应,以实现高置信度检测。
  • Verify email and phone numbers at signup; track signup velocity.
    中文:[ ] 在注册时验证电子邮件和电话号码;跟踪注册速度。
  • Enforce per-account purchase, address, and payment-method limits on scarce inventory.
    中文:[ ] 对稀缺库存实施按账户购买、地址和支付方式限制。
  • Sign API requests; advertise quotas via X-RateLimit-* headers.
    中文:[ ] 对API请求进行签名;通过X-RateLimit-*头广告配额。
  • Log decisions with signals; build anomaly dashboards.
    中文:[ ] 使用信号记录决策;构建异常仪表板。
  • Mask PII and rotate raw signal storage on a short schedule.
    中文:[ ] 隐藏PII并按短期计划轮换原始信号存储。
  • Document anti-bot processing in your privacy notice.
    中文:[ ] 在您的隐私通知中说明反机器人处理过程。
  • Provide accessibility alternatives to any user-facing challenge.
    中文:[ ] 为任何面向用户的挑战提供可访问性替代方案。

References / 参考