Stop subscription bombing on a static site's signup form
If your static site has a newsletter, waitlist or contact form, bots will find it, and the damage lands on strangers: your form sends a confirmation email to an address that never asked. Here is what the attack looks like, what reduces it, and what no static-site fix can promise.
What it is
Subscription bombing signs a victim's address up to many sites at once so that real mail, such as a security alert, is buried. One writer who ran a product's signup form described low-volume traffic, one or two signups an hour with slow, uneven typing, that slipped past simple rate limits; their fix was Cloudflare Turnstile plus sending only the verification email until the address is verified (their write-up, discussed on Hacker News, April 2026). A smaller version is common on newsletters: a site owner reported a bot trying to subscribe a random address "approximately 5-10 times a day", every confirmation bouncing or going unread, and worried about their email reputation (November 2025).
The measures, cheapest first
- Send nothing to an unverified address except one confirmation. No welcome series, no "thanks for your message" auto-reply. The victim's worst case is one email.
- Remember you already asked. If a confirmation went to this address in the last day, answer the form the same way and send nothing. This turns "300 bots, one victim" into one email.
- Confirm with a button, not a link. Mail scanners and link previews open every link. If opening the link subscribes the person, a scanner can confirm a stranger's address. Make the link show a page and put the action behind a POST.
- A hidden honeypot field. Cheap and invisible to people. Answer "success" when it is filled so the bot learns nothing. It stops simple form-fillers only.
- Proof of work, tied to the address. The browser finds a number that makes a hash start with zeros. A real visitor pays a fraction of a second; a bot posting thousands pays for each one, and a solution for one address is useless for another. It adds cost, it does not identify bots: a real browser pays it too.
- Per-IP and daily ceilings. A fuse so a determined attacker burns a day's allowance rather than your sender reputation. The price is that real visitors are turned away until the next day, so choose the number knowingly.
- Fail closed. If your store or email provider is unavailable, send nothing.
What these measures did in a simulation
These rows are the output of the attack simulator in Signup Shield Kit, run against its real Worker code with a memory store. They are scripted attacks, not a field result: a real attacker can be cleverer, which is why the row about a botnet that pays the work ends at the daily ceiling.
| Scenario | Attempts | Confirmation emails sent |
|---|---|---|
| 1. Naive bot posts 1,000 random addresses, no proof of work | 1000 | 0 |
| 2. Form-filling bot fills the hidden honeypot field, 1,000 times | 1000 | 0 |
| 3. Bot solves the proof of work, one IP, 200 random addresses | 200 | 5 |
| 4. Botnet: 300 IPs each solve the work, 300 random addresses | 300 | 100 |
| 5. Subscription bomb: 300 IPs all target ONE victim address | 300 | 1 |
| 5b. Same bomb, but all 300 requests are fired in parallel | 300 | 1 |
| 6. Replay one solved proof against 200 different addresses | 200 | 1 |
| 7. Same as 6 but the bot posts instantly (before the minimum age) | 200 | 0 |
| 8. Real visitors: 40 people from 40 IPs subscribe | 40 | 40 |
| 9. Storage quota used up (storage writes fail), then 50 real visitors | 50 | 0 |
| 10. Mailbox variants: 300 IPs target ONE Gmail inbox as [email protected], v.ictim@, [email protected] | 300 | 1 |
| 11. Contact form: one solved proof reused for 200 different messages from 200 IPs | 200 | 1 |
| 12. Contact flood that pays the work for every message (200 IPs), then one real signup | 201 | 31 |
| 13. One IPv6 /64 (50 addresses in the same network) signs up 50 random addresses | 50 | 5 |
What this does not do
A bot that drives a real browser, or copies the short solver, pays the proof of work and gets through, and a large enough botnet can use up the day's ceiling with random addresses. Cloudflare Turnstile and similar services judge the visitor with signals a static site cannot see, which is why the author above chose it; some people avoid it because it sends data to a third party, a worry raised in the Hacker News discussion of proof-of-work captchas (April 2026). Pick the trade-off that suits your audience. You can combine them: proof of work first, a third-party check only if you are still attacked.
Try the cost on your own device
The free proof-of-work tester runs the same solver in your browser and shows how long each difficulty takes on your hardware, so you can pick one that does not punish people on old phones.
If you want it done
You can build all of this yourself; each part is small, and the order matters more than the code. Signup Shield Kit is the version already assembled and tested: a Cloudflare Worker, three sample sites, docs and the simulator, for $15 once.