CAPTCHA & Abuse Prevention
Purpose
Keep bots and automated abuse off public endpoints using CAPTCHA and complementary bot signals — verified server-side, layered with rate-limiting. Abuse prevention filters non-human/mass traffic; it is not authorization and grants nothing.
When to Use
- For public, unauthenticated, or bot-attractive flows: signup, login, password reset, OTP request, contact forms, public search, expensive endpoints.
- Not for deciding access rights (
backend-authorization) and not on flows where friction is unjustified by observed or expected abuse.
Inputs
- Public-endpoint inventory + rate-limit design (
rate-limiting).
- UX constraints (client platforms, accessibility requirements).
Discovery Questions
- Which flows are bot targets today or at launch (signup spam, credential stuffing, OTP pumping, contact spam, scraping)?
- What CAPTCHA style fits the UX (invisible/score-based vs challenge) and which flows justify hard friction?
- What non-CAPTCHA signals are available (honeypot fields, submit timing, disposable-email checks, IP reputation)?
Responsibilities
- Map flows to protections, escalating with abuse pressure:
- Signup: CAPTCHA (bots create accounts for everything downstream) + disposable-email policy + rate limit.
- Login: score-based/invisible CAPTCHA, escalating to challenge after failures — layered on the login rate limits.
- Password reset / OTP request: CAPTCHA before send (each send costs money and spams victims) + tight rate limits; OTP pumping is a financial attack.
- Contact forms: CAPTCHA or honeypot+timing at minimum.
- Public search / scraping targets: prefer rate limits + bot heuristics; CAPTCHA only under attack (search friction is costly).
- Expensive endpoints: prefer authentication + rate limits/queues; CAPTCHA if they must stay public.
- Verify tokens server-side with the provider on every protected request — client-side "verified" flags are theater; tokens are single-use and short-lived.
- Plan failure handling: provider outage policy (fail open vs closed per flow — record it), score thresholds, escalation ladder (invisible → challenge → block).
- Keep accessibility in view: audio/alternative challenges; never CAPTCHA-only lockout for assistive-tech users.
- Monitor effectiveness: solve rates, failure spikes, abuse-through rates (
backend-observability).
Required Workflow
- Inventory bot-attractive flows; assess abuse pressure per flow.
- Choose protection per flow (CAPTCHA style, complementary signals) and escalation ladder.
- Design server-side verification (token flow, single-use, timeout, outage policy).
- Layer with rate limits — neither replaces the other.
- Specify tests: missing/invalid/replayed token rejected server-side; honeypot triggers rejection.
Decision Rules
- Server verification is the control; the widget is UX.
- CAPTCHA reduces automation, rate limits reduce volume, authorization decides rights — three layers, no substitutions in either direction.
- Start invisible/score-based; escalate friction only where signals or incidents justify it.
- Auth-flow verification fails closed (no bypass when the provider is down without an explicit, recorded exception); low-risk forms may fail open.
Rules
- Every protected flow verifies the token server-side, single-use.
- Secrets (provider keys) follow
backend-security handling.
- Record per-flow decisions including "no CAPTCHA because…" — absence is a decision too.
Anti-Patterns
- Client-side-only CAPTCHA validation.
- Treating a solved CAPTCHA as authentication or authorization.
- CAPTCHA on every request instead of abuse-attractive flows (UX tax, no gain).
- No protection on OTP/SMS senders (toll fraud magnet).
- Accepting the same CAPTCHA token repeatedly (replay).
Validation Checklist
Definition of Done
A recorded per-flow abuse-prevention design — CAPTCHA style, complementary signals, server-side single-use verification, outage policy, escalation ladder — layered with rate limiting and never standing in for authorization.
Related Skills
rate-limiting, backend-authentication, backend-authorization, backend-security, backend-observability, third-party-integrations (provider client), email-notifications (send-triggering flows).
Related Knowledge
../../../knowledge/ (abuse history, UX constraints).
Related References
../../../references/backend/abuse/ (flow-protection table, when populated).
Context Loading Guidance
- Requires: public-flow inventory, rate-limit design, UX constraints.
- Does not require: authorization matrix, provider SDK docs.
- May load:
rate-limiting (layering), backend-observability (monitoring).
- Stop when: per-flow protections + verification design + tests are recorded.
Token Efficiency Guidance
The flow × protection table carries the design; keep provider specifics to a link in references.
1---2name: captcha-abuse-prevention3description: Use to plan CAPTCHA and bot-abuse prevention for public endpoints — signup, login, password reset, OTP, contact forms, public search, expensive endpoints. Server-side verification, layered with rate limiting; never a substitute for authorization.4---56# CAPTCHA & Abuse Prevention78## Purpose910Keep bots and automated abuse off public endpoints using CAPTCHA and complementary bot signals — verified **server-side**, layered with `rate-limiting`. **Abuse prevention filters non-human/mass traffic; it is not authorization and grants nothing.**1112## When to Use1314- For public, unauthenticated, or bot-attractive flows: signup, login, password reset, OTP request, contact forms, public search, expensive endpoints.15- **Not** for deciding access rights (`backend-authorization`) and not on flows where friction is unjustified by observed or expected abuse.1617## Inputs1819- Public-endpoint inventory + rate-limit design (`rate-limiting`).20- UX constraints (client platforms, accessibility requirements).2122## Discovery Questions2324- Which flows are bot targets today or at launch (signup spam, credential stuffing, OTP pumping, contact spam, scraping)?25- What CAPTCHA style fits the UX (invisible/score-based vs challenge) and which flows justify hard friction?26- What non-CAPTCHA signals are available (honeypot fields, submit timing, disposable-email checks, IP reputation)?2728## Responsibilities2930- Map flows to protections, escalating with abuse pressure:31 - **Signup**: CAPTCHA (bots create accounts for everything downstream) + disposable-email policy + rate limit.32 - **Login**: score-based/invisible CAPTCHA, escalating to challenge after failures — layered on the login rate limits.33 - **Password reset / OTP request**: CAPTCHA before send (each send costs money and spams victims) + tight rate limits; OTP pumping is a financial attack.34 - **Contact forms**: CAPTCHA or honeypot+timing at minimum.35 - **Public search / scraping targets**: prefer rate limits + bot heuristics; CAPTCHA only under attack (search friction is costly).36 - **Expensive endpoints**: prefer authentication + rate limits/queues; CAPTCHA if they must stay public.37- **Verify tokens server-side** with the provider on every protected request — client-side "verified" flags are theater; tokens are single-use and short-lived.38- Plan failure handling: provider outage policy (fail open vs closed per flow — record it), score thresholds, escalation ladder (invisible → challenge → block).39- Keep accessibility in view: audio/alternative challenges; never CAPTCHA-only lockout for assistive-tech users.40- Monitor effectiveness: solve rates, failure spikes, abuse-through rates (`backend-observability`).4142## Required Workflow43441. Inventory bot-attractive flows; assess abuse pressure per flow.452. Choose protection per flow (CAPTCHA style, complementary signals) and escalation ladder.463. Design server-side verification (token flow, single-use, timeout, outage policy).474. Layer with rate limits — neither replaces the other.485. Specify tests: missing/invalid/replayed token rejected server-side; honeypot triggers rejection.4950## Decision Rules5152- Server verification is the control; the widget is UX.53- CAPTCHA reduces *automation*, rate limits reduce *volume*, authorization decides *rights* — three layers, no substitutions in either direction.54- Start invisible/score-based; escalate friction only where signals or incidents justify it.55- Auth-flow verification fails **closed** (no bypass when the provider is down without an explicit, recorded exception); low-risk forms may fail open.5657## Rules5859- Every protected flow verifies the token server-side, single-use.60- Secrets (provider keys) follow `backend-security` handling.61- Record per-flow decisions including "no CAPTCHA because…" — absence is a decision too.6263## Anti-Patterns6465- Client-side-only CAPTCHA validation.66- Treating a solved CAPTCHA as authentication or authorization.67- CAPTCHA on every request instead of abuse-attractive flows (UX tax, no gain).68- No protection on OTP/SMS senders (toll fraud magnet).69- Accepting the same CAPTCHA token repeatedly (replay).7071## Validation Checklist7273- [ ] Bot-attractive flows inventoried (signup, login, reset, OTP, contact, search, expensive considered).74- [ ] Protection + escalation per flow recorded.75- [ ] Server-side, single-use verification designed with outage policy.76- [ ] Layered with rate limits; distinct from authorization everywhere.77- [ ] Accessibility fallback present.78- [ ] Tests: invalid/missing/replayed tokens rejected.7980## Definition of Done8182A recorded per-flow abuse-prevention design — CAPTCHA style, complementary signals, server-side single-use verification, outage policy, escalation ladder — layered with rate limiting and never standing in for authorization.8384## Related Skills8586`rate-limiting`, `backend-authentication`, `backend-authorization`, `backend-security`, `backend-observability`, `third-party-integrations` (provider client), `email-notifications` (send-triggering flows).8788## Related Knowledge8990`../../../knowledge/` (abuse history, UX constraints).9192## Related References9394`../../../references/backend/abuse/` (flow-protection table, when populated).9596## Context Loading Guidance9798- **Requires:** public-flow inventory, rate-limit design, UX constraints.99- **Does not require:** authorization matrix, provider SDK docs.100- **May load:** `rate-limiting` (layering), `backend-observability` (monitoring).101- **Stop when:** per-flow protections + verification design + tests are recorded.102103## Token Efficiency Guidance104105The flow × protection table carries the design; keep provider specifics to a link in references.
ahtishamshahzad