Subscription bombing and how to mitigate it
Attackers are increasingly abusing signup and “change credit card” forms to launch “subscription bombing” campaigns, flooding victims’ inboxes with automated emails so real security alerts or fraud notices are buried. Commenters debate how to defend against this: email verification, CAPTCHAs, Cloudflare Turnstile, honeypot fields, rate limiting, proof-of-work, and anomaly detection on payment flows all surface, but each raises trade-offs in usability, false positives, and centralization of power in large anti-bot providers. Many also criticize companies for sending multiple unsolicited emails or skipping basic email verification entirely, arguing that growth and marketing goals are routinely prioritized over user privacy and safety.
Scope of the Problem & Attack Goals
- Subscription/email bombing is described as cheap, commoditized (“as a service”), and often used to hide other actions (e.g., account takeover, card fraud, fake listings) or simply to harass.
- Victims report hundreds to thousands of emails in hours, often from legitimate services (gov sites, e‑commerce, newsletters, support forms).
- Some attacks appear to be pure inbox DoS with no obvious secondary fraud, which several commenters find puzzling.
Email Verification, UX Friction & Business Incentives
- Many argue that not verifying email addresses is negligent, leading to privacy leaks (bank transfers, medical data, legal documents, court cases, mortgage info) to the wrong person.
- Others note companies deliberately avoid verification to reduce friction and preserve impulsive purchases or easy signups.
- Several call for regulation or even legal penalties for sending non‑verification emails to unverified addresses.
- Suggested best practice: send only a single verification email, and no welcome/newsletter messages until verification and some meaningful user engagement.
Mitigations on Signup & Forms
- Common defenses mentioned: CAPTCHAs/Turnstile, honeypot fields, simple math/image CAPTCHAs, inbound email checks, username/email entropy checks, LLM-based “gibberish” filters, and browser proof‑of‑work.
- Honeypots and simple CAPTCHAs work against unsophisticated bots but can be bypassed; hidden fields may break accessibility or password managers.
- Proof‑of‑work and rate limiting are seen as cheap and effective for some, but others say generic rate limiting and heuristic rules are hard to tune and maintain.
Cloudflare, Centralization & CAPTCHA Skepticism
- Some see Cloudflare/Turnstile as pragmatic and effective, especially in “normal” (non‑invisible) mode.
- Others strongly oppose relying on a single large provider, citing centralization, outages, privacy, and degraded UX (especially for VPN/Starlink/mobile users).
- There is disagreement on how easily modern CAPTCHAs are bypassed; some point to paid CAPTCHA-solving services and advanced bots, others say big providers still block most low‑effort abuse.
Payment & Card‑Testing Abuse
- A related pattern: attackers use “change credit card” flows and $1 authorization/refund checks to validate stolen card lists.
- Suggested mitigations include: only allowing card changes on accounts with valid existing cards, limiting very small charges, stronger anomaly detection, “silent blocks” that fake declines, and processor‑level fraud controls.
- Debate over where fraud detection should live: at the site vs. the payment processor; processors can detect patterns across merchants but also push risk and penalties back onto sites.
Alternatives & Radical Ideas
- Proposed but controversial alternatives:
- Reversing email flow (user initiates signup by sending an email).
- Eliminating email from auth entirely or replacing it with RSS-style inboxes or third‑party identity providers.
- Many point out such flows are unfamiliar, high‑friction, and likely to crush conversion, so adoption is unlikely.