Job form-spam-and-validation-hardening · revised 11 October 2026
Stop junk submissions on one web form without blocking real people
One named form rejects a fixed set of junk submissions on the server and still accepts a fixed set of genuine ones, including unusual names and addresses. You review and release the change.
You might be seeing
- Many submissions arrive with random text, links or the same message from different addresses
- Submissions arrive even though the visible form was never used, which suggests scripts posting directly
- A genuine person is told their name or email address is invalid
No passwords, keys, card details or admin invites needed to start.
What usually happened
The form's checks live only in the browser, so a script can post to the address behind the form and skip them, while the browser-side rules are also too narrow for real names and addresses. The job adds server-side validation and a small set of low-friction spam controls to one form, then proves it with a fixed set of junk and genuine test submissions.
Who it’s for: A business owner or product owner whose website or app has one public form (contact, signup, quote request) that is flooded with junk or script-generated submissions, or that rejects real people because its checks are too strict.
Usually starts when: The inbox, spreadsheet or database behind the form fills with junk, or a real customer reports that the form refused their name or email address.
The result: The named form's server rejects every item in an agreed list of junk test submissions with a clear internal reason and accepts every item in an agreed list of genuine ones, including names with accents, apostrophes and single words and addresses with plus signs. Real people see a helpful message when something is wrong.
Check whether this job fits
These questions check whether the problem is server-side junk and over-strict rules in one form. They need no submissions, credentials or code.
Checks you can run yourself
Look for submissions that skipped the page
In your submissions list, check whether any arrive with fields the visible form cannot produce, an impossible combination (for example an empty required field), or timestamps seconds apart. Read them only; do not delete anything yet.
Look for: Patterns that suggest a script posting straight to the form's address rather than a person using the page.
What you get
- A pull request with the server checks, the controls and the tests
- The junk and genuine test sets, with the expected result for each
- A short note explaining each control, what it can and cannot stop, and how to change a threshold
- Reversal steps and any limits found
Included
- One public form and its receiving server code, in one codebase
- Server-side checks for required fields, length limits, expected formats and obviously invalid combinations, with messages for real people
- A hidden decoy field and a minimum-time check, plus a simple limit on repeat submissions from one source, chosen by us to fit the form
- Review and loosen browser-side rules that reject genuine names or addresses
- A test set of at least twenty junk and ten genuine submissions, built with you from real patterns you describe
- Where you already hold keys for a challenge service, wiring it in; we do not open an account for you
Not included
- Email delivery problems, which are a separate job (see the contact-form email repair)
- Opening accounts with, or paying for, a challenge or spam-filtering service
- Blocking determined human spammers or targeted abuse, and any guarantee that no junk gets through
- Cleaning or deleting junk already stored, or reviewing past submissions
- Several forms, a new form builder, or a redesign of the page
- Production deployment, which stays with your team
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every item in the agreed junk test set is rejected by the server code when posted directly to the form's address without using the page, and none is stored or forwarded.
Evidence: The test list with each item's expected result and the recorded server response for each.
Every item in the agreed genuine test set is accepted and stored, including a name with an accent, a name with an apostrophe, a single-word name and an email address containing a plus sign.
Evidence: The test list and the stored test records, which are removed afterwards.
When a real person makes an error, the form shows a message that names the field and the problem in text, and keeps what they typed.
Evidence: Screenshots of the message for each rule on desktop and phone widths.
The diff contains no secret, the decoy field is not announced by a screen reader, and the existing form tests still pass.
Evidence: The changed-file list, a secret scan of the diff, a screen reader check note and the test results.
Sign-off. You or your authorised maintainer review the test results, try the form yourself on the copy, sign off in writing and merge. Payment follows sign-off.
If it fails. If either test set does not pass, you do not pay for this fixed scope. If the junk cannot be reduced by the agreed controls without blocking real people, we tell you plainly and stop. Wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- The form posts to code in a codebase we can inspect through an agreed route, not a hosted form tool whose rules you cannot change
- You can supply a few anonymised examples of the junk and of genuine submissions, with personal details removed
- The form can be exercised on a copy that does not email real customers or write to the live store
- An authorised maintainer on your side reviews and merges the change
We stop and tell you if
- The form is a hosted widget whose server rules you cannot change; we explain which settings in that tool to use instead
- The junk comes from authenticated users or from your own systems rather than the public form
- Meeting the target would require blocking by country, device identity or personal data profiling
What could go wrong
Before merge, closing the pull request leaves the form unchanged. After merge, your maintainer can revert the commit. Each control can also be switched off on its own through the setting we document.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A rule blocks real customers and costs you enquiries. | The genuine test set includes accents, apostrophes, single names, plus-signs in addresses and long values, and every item must pass. Thresholds are documented so you can loosen them. |
| A hidden decoy field interferes with screen readers or autofill. | The field is hidden from assistive technology and excluded from autofill, and the reviewer checks it. |
| Junk adapts and some still arrives. | We state that no control stops all junk and we agree a realistic target with you before work starts. |
An independent reviewer checks that each rule rejects only what it should, that genuine unusual names and addresses pass, and that the controls do not hide a form from assistive technology. Your maintainer reviews and merges.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- OWASP explains why a server must validate even when the browser already checks, and why an allowlist beats a blocklist. A developer can apply it without outside help. cheatsheetseries.owasp.org
- If you already pay for a form tool, its built-in spam settings may be enough and cost nothing extra.
Questions
Will this stop all spam?
No. The controls stop script-generated junk and repeat flooding. A human who writes unwanted messages by hand can still get through, and we say so before you buy.
Do I need a CAPTCHA?
Not necessarily. Many forms are fixed by server checks and a hidden decoy field. A challenge service is used only if you already hold its keys and want it.
Is this the same as emails not arriving?
No. This job is about what the form accepts. If submissions are accepted but notification emails do not arrive, that is a separate sending-path repair.
Will real people be blocked?
We test for that on purpose with a genuine set that includes unusual names and addresses, and every item must pass.
Send an enquiry
Send us
- Which form, which technology it is built with and where its submissions go
- Three to five anonymised examples of the junk, and one example of a genuine submission that was refused, with personal details removed
- Roughly how often junk arrives, as you observe it
- Do not send real customer submissions, source code, an access invitation or credentials in the first enquiry
Later, once you agree
- The form and receiving code through an agreed company-controlled route, with a branch for the pull request
- A copy where submissions go to a test store and any email is switched off
- Anonymised junk and genuine examples, agreed as the test sets
- The name of the person who reviews and merges
You own the site, the form and its stored submissions. We work on a branch or copy through a company-controlled identity, never a personal login, using only anonymised examples. We never receive live submissions. Your team deploys and sets any thresholds in production.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “form-spam-and-validation-hardening” as the subject.