From Code to Kanji

Forms look simple. A few fields, a submit button, maybe some nice rounded corners. To your users, they’re just boxes to type into. But to bots, they’re invitations. Every form is a door and where there’s a door, someone will try to kick it down.

Brute force attacks aren’t the cinematic kind. There’s no hoodie wearing hacker furiously typing, no green progress bar inching toward 100%. The real version is much more boring. A script that submits your form thousands of times per second, trying to flood your inbox, poison your data, or slip past your defenses.

Most developers respond by bolting on Google reCAPTCHA v3 and calling it a day. It’s a decent start which I’ve implemented it myself but it’s only one piece of a bigger puzzle. Securing forms isn’t about finding a single tool. It’s about layering defenses in a way that frustrates attackers while staying invisible to real humans. The art is to make bots feel like they’re running uphill in mud while legitimate users stroll through without even noticing.

Here’s how to do it.

Rate Limiting

The first line of defense is speed control. Imagine you’re running a coffee shop, and a customer tries to order 200 cappuccinos in the span of one minute. You’d know something strange was going on. Rate limiting does the same for forms. It caps how many submissions an IP address or session can make in a given timeframe.

For example, a contact form might allow three submissions per minute per IP. Anything beyond that gets blocked or delayed. A normal human filling out a feedback form won’t notice this ceiling. A bot hammering your form, on the other hand, will slam into a wall almost instantly.

Rate limiting doesn’t just block brute force, it also helps protect your backend resources. Without it, one spammer can drown your database or email system in junk. With it, you stop the flood before it starts.

Progressive Delays

Rate limits are good, but sometimes you don’t want to shut the door, you just want to make it heavier to push. Progressive delays achieve this by slowing down responses after repeated submissions.

On the first submission, the response is immediate. On the second, it takes two seconds. On the third, maybe five. By the tenth, the bot is waiting thirty seconds just to get a “submission failed” message. Multiply that delay across thousands of attempts, and suddenly the attack becomes infeasible.

The beauty of progressive delays is how gentle they are for real users. A human might mistype something once or twice and never feel the slowdown. But a script designed to blast through endless requests will grind to a halt.

It’s like quicksand, the harder the bot struggles, the slower it moves.

Temporary Blocks and Quotas

Sometimes a delay isn’t enough. If a user (or bot) keeps hammering past the limit, you can suspend them for a period of time. This is where temporary blocks come in.

Take a signup form. You might allow five failed attempts per IP per hour. Once they cross that line, you block submissions from that IP for the next 24 hours. For high value forms like “reset password” or “apply for account deletion” you can be even stricter.

Another variation is quotas: setting a cap on how many times a form can be submitted per day. A user doesn’t need to send 500 feedback messages in 24 hours. A bot, however, will try. Quotas ensure that your inbox, logs, and database aren’t buried in repetitive junk.

This is about balance. You’re not punishing legitimate users, because nobody naturally behaves like a spam bot. You’re just setting a rhythm that matches human behavior.

Honeypot Fields

Now for one of my favorite tricks: honeypots. These are invisible form fields that humans never see but bots blindly fill.

Picture this: you add a field called phone_number_alt to your contact form, but you hide it with CSS (display: none;). A real user never notices it. But a bot, which just parses the HTML and dumps data into every input it finds, will happily enter “1234567890” there. The moment your server sees data in that field, it knows this submission isn’t human.

Honeypots are brilliant because they’re cheap, invisible, and don’t disrupt the user experience at all. No captchas, no friction, just quiet filtering. They won’t stop sophisticated bots that simulate browsers, but they catch a surprising amount of low-effort spam. It’s like putting a fake door on your house and watching burglars walk right into it.

IP Reputation and Geo Checks

Not all traffic is created equal. If your user base is local but you suddenly see thousands of submissions from data centers on another continent, you have a problem.

This is where IP reputation and geo checks help. By integrating with IP intelligence services or even using db lookup like I’ve posted here, you can flag known bad networks, anonymizers, or unusual geographies. For example, if your form is meant for Indonesian customers, but a flood of entries suddenly arrives from a botnet in Eastern Europe, you can block or challenge them.

Geo checks aren’t foolproof as VPNs exist, and not every “suspicious” IP is malicious. But combined with other signals, they help you filter out the noise early, before it hits your app. Think of it as bouncers at the door, turning away guests who clearly don’t belong at the party.

CAPTCHAs and Challenges

This is the defense most people know: CAPTCHAs. Love them or hate them, they work, at least to a degree.

Google’s reCAPTCHA v3 runs quietly in the background, scoring traffic for suspicious behavior without bothering real users. If the score looks bad, you can escalate, show a puzzle, ask for a checkbox, or even challenge with a slider. Other services use different forms of “human proof” tests.

The key with CAPTCHAs is to use them sparingly. If every form submission demands “click all the pictures of bicycles,” your users will rage. But if you trigger them only when traffic looks suspicious, high frequency, odd IP ranges, weird patterns they’re effective at raising the cost of automation.

CAPTCHAs are not silver bullets, but as one layer in the onion, they’re valuable.

Content Validation

Sometimes brute force isn’t about guessing passwords. It’s about flooding your system with garbage. That’s why validating the content of submissions is important.

Does your contact form suddenly receive hundreds of identical “Buy cheap sunglasses” messages? Reject them. Does the feedback field contain nothing but random characters or repeated links? Flag it. Even simple rules like banning excessive links, checking for known spam phrases, or requiring a minimum length can filter out automated junk.

This defense doesn’t just reduce brute force, it keeps your inbox, logs, and databases clean. And when combined with the other techniques, it ensures that even if spam slips past, it doesn’t pollute your system.

Multi-Factor Where It Matters

Not every form needs this, but for critical actions, it’s worth adding a secondary check.

Take a password reset form. If someone requests a reset, don’t just send the email, also require them to confirm their identity through a one time code. Or for sensitive account changes, require re-authentication before accepting the form submission.

These extra layers make brute force meaningless. Even if an attacker can hammer the form, they can’t complete the process without access to the second factor. It’s overkill for a simple “contact us” form, but for high-value forms, it’s essential.

Conclusion

Every form is a target. Brute force attacks aren’t just about breaking into accounts, they’re about spamming your inbox, wasting your server resources, and testing how sloppy your defenses are.

Relying on a single tool like reCAPTCHA won’t cut it. The real answer is defense in depth. Rate limiting, progressive delays, temporary blocks, honeypots, IP reputation, CAPTCHAs, content validation, and multi factor for sensitive cases. Each layer adds friction for bots while remaining invisible to humans.

Security is never about perfection, it’s about raising the cost. Bots are opportunistic. They don’t want a challenge, they want low hanging fruit. If your forms are sticky, slow, and expensive to attack, they’ll move on to someone else. And your users will never even notice, which is exactly how it should be.