pekarunagyker.hu — a form the bots cannot eat
The task
In wholesale, an incoming enquiry is worth money: every line is a potential customer. But that same input point is also the favourite target — automated fillers try their luck hourly. There are two bad outcomes: spam floods the inbox (and the real enquiry is lost in it), or the protection is so strict that genuine prospects get stuck too.
The solution: five layers, in order
- Origin check. A submission may only come from the site's own pages. Anything from elsewhere is rejected by the server before it even reads the data.
- Honeypot field. A hidden field a human never sees and never fills in. An automated filler, however, fills in every field — and gives itself away. The response is deliberately "successful", so the bot does not learn from its mistake.
- Size limit. An oversized request body never reaches the application: it is stopped at server level. This is the layer that protects most cheaply against load-based attempts.
- Human verification. A cookie-free check, clean from a privacy standpoint, that does not burden the visitor with picking out images.
- IP rate limit. A limited number of submissions per address per hour. This is not the main filter against bots but the defence against what is left — and it sits in front of the expensive operations, so an attacker cannot use them to put the server to work.
What happens after the form
The enquiry is written to disk first, and only then does the email go out. This order is deliberate: if the mail service goes down, the prospect is still not lost. If the email does fail to go out, the log gives it away immediately.
The outgoing notification is sent with an authenticated sender (SPF and DKIM), and the prospect's address is set as the reply-to — so replying is one click, not copying and pasting.
The server side
The service receiving the form runs as a separate, restricted process: it cannot see outside its own directory, cannot elevate privileges, cannot touch the rest of the system, and works under memory and process limits. If it did contain a vulnerability, this frame bounds the damage.
Check it yourself
- pekarunagyker.hu — the live site; the quote request form can be tried out.
- Submit an empty form: you immediately see what the system says, and how much the error message gives away (deliberately little).
- PageSpeed Insights — speed measured with Google's own instrument.
What can be learned from it?
That form protection is not a switch but an order of operations. The layers stack from cheap to expensive: first what can be decided from reading one header, last what requires calling an external service. That order decides whether an attacker can make your server do work for them.
If your revenue also arrives through a form: custom website development. A detailed breakdown of the protection layers in a separate article: how a quote request form protects against spam.