Fraud & Bot Prevention
Paid clinical research recruitment sees bot and fraudulent-response rates estimated as high as 50% industry-wide. TrialConnect's forms don't collect payment or compensation directly, but the same automated submitters target any public email-capture or contact form. Here's what stands between them and our data.
1. Honeypot Fields
Every public capture form — trial alert sign-up, the waitlist, and the trial-contact form — includes a hidden field that is invisible and unreachable to a real visitor (it sits off-screen and is skipped by keyboard tab order). Simple bots that fill in every input on a page fill this field too. Any submission where it's non-empty is treated as automated: we silently drop the record rather than persisting or emailing it, and we return the same success response a genuine submitter would see, so the bot has no signal to adapt its behaviour.
2. Timestamp Sanity Checks
Each form records the moment it first rendered in the visitor's browser and sends that alongside the submission. If a submission arrives implausibly fast — faster than a person could plausibly read the form and type into it — we log it as a suspicious-fast signal for review.
We deliberately treat this as a signal, not a block. Browser autofill and password managers can legitimately submit a form very quickly, and rejecting those submissions would turn away real patients — a worse outcome than letting an occasional fast bot through. Only the honeypot check above results in a submission being dropped.
3. Rate Limiting
TrialConnect layers rate limits at two levels:
- Platform-wide: every
/api/*request is limited per client IP (verified server-side, not the client-supplied header) to guard against blunt-force flooding of any endpoint. - Per-form: the trial-contact enquiry endpoint additionally limits submissions to a small number per IP hash and per browser session within a rolling 24-hour window, independent of the platform-wide limit. This catches a single visitor hammering one form even if they're well under the site-wide ceiling.
Rate limits return a standard 429 response with a Retry-After header — the same behaviour a real visitor would see if they genuinely tried to resubmit too quickly.
4. Duplicate Detection
Trial alert sign-ups are keyed on the combination of email address and condition: resubmitting the same pair re-triggers the double opt-in confirmation instead of creating a duplicate subscription row. No alert is ever sent, and no subscription is marked active, until the recipient clicks the confirmation link in that email — a bot that submits fake addresses at scale never produces a live subscription.
5. Human Confirmation Step
Trial alerts use double opt-in: submitting the form only sends a confirmation email, and no alert is ever delivered until that link is clicked. This is, in effect, a human-verification step — an automated submitter that can't also access and click a link in a real inbox never produces a working subscription.
Questions?
If you believe a submission was wrongly blocked, or you're a sponsor with questions about data integrity on referrals, contact us at admin@trialconnect.co.uk.
See also our Privacy Policy for how submitted data is stored and used.