Public-facing forms, contact forms, waitlist signups, review submissions, comment boxes, get built and tested by a human filling them out once or twice, confirming the submission works, and moving on. What rarely gets checked is what happens when something other than a human, a simple script, submits the same form thousands of times in a row.
Why this matters even when there's nothing valuable to steal
This is a different category of risk than most of what I write about. Nobody's trying to read someone else's data through a spammed contact form. The cost here is different: a flooded inbox, a database full of fake waitlist signups, an email service that starts rate-limiting or suspending your account because of abuse volume, or in the case of anything that triggers a paid action per submission, a real and growing bill.
What actually happens without any protection
A basic script can submit a public form hundreds or thousands of times in a short window with no real effort, since there's nothing checking whether the submission came from a person clicking through a browser or an automated request hitting the endpoint directly. Every one of those effects, the flooded inbox, the fake signups, the exhausted email quota, follows automatically once volume like that exists with nothing standing in its way.
The basic protections worth having, from simplest to most robust
- A honeypot field: a form field that's hidden from real visitors through styling but visible to basic bots that fill out every field they find. If that hidden field gets filled in, silently reject the submission. Free, invisible to real users, and catches a surprising amount of unsophisticated spam.
- A rate limit on the submission endpoint itself, the same kind I've written about for login forms, capping how many submissions can come from the same source in a given window.
- A CAPTCHA or similar human-verification step for anything especially exposed to abuse, a public signup with no other friction, though this adds real friction for genuine users and is worth reserving for forms that actually need it.
- Basic server-side validation confirming submitted fields look like what they're supposed to (a real-looking email format, a reasonable length), which won't stop a sophisticated bot but closes off the laziest, most common automated abuse.
How to actually check your own forms
Look at each public-facing form your app has and ask, honestly: what stops a script from submitting this a thousand times right now? If the honest answer is nothing, that's worth a basic fix, starting with the free options above before reaching for anything that adds friction to real users.
This category of protection rarely makes it onto a security checklist because it doesn't expose anyone's data. It still costs real money, real time, and real inbox sanity once a form gets found by whatever automated systems are constantly crawling the internet looking for exactly this kind of unprotected target.