Member Avatar for Octet

I am creating a website although during a trial run with a couple of friends they uncovered a bit of a major issue.... the ability to spam.
I have added a hidden box e.t.c. to attempt to prevent bots from spamming but my friends where able to post twenty messages in about one minute which obviously isn't good.

I am not entirely sure where this would go as it is a general sort of thread to do with Web Design so I placed it here.

Does anyone have any ideas on how I can either restrict the number of posts someone can send per minute (all forums require a login but the 'Contact Form' doesn't) or any other method I could use?

Thanks

  • 4 Contributors
  • 3 Replies
  • 236 Views
  • 3 Days Discussion Span
  • Latest Post Latest Post by nielsep

Dani AI

Generated

As 's test showed (20 contact-form messages in ~1 minute), a visible honeypot alone is easy to bypass. The safest route is a layered, server-side strategy that combines lightweight friction with targeted challenges so legitimate senders aren't inconvenienced while automated floods are stopped.

Build on the ideas from , and but harden them server-side: issue a single‑use token when the form is rendered and store a server timestamp; reject tokens that are reused or older than a short window. Require a minimum reasonable time between page render and submit (very short times are usually bots) and validate Origin/Referer and a server-side session/cookie if available. Never trust client-side checks alone — all validation and throttling must happen on the server.

Score each submission instead of taking one binary action: combine IP frequency, token age/reuse, time‑to‑complete, number of links or suspicious keywords, user‑agent anomalies and whether JavaScript-set fields exist. If the score crosses a threshold, present a challenge (adaptive captcha or human review), return a 429-like backoff, or queue the message for moderation. Use exponential backoff for repeat offenders so automated retries become expensive.

Practical cautions and starting points: avoid blanket IP bans (shared NATs and mobile carriers exist); begin with conservative limits (for example, a short min submit interval, then escalate to 1–5 submissions/hour per IP depending on traffic) and tune from logs. Keep a flagged queue and clear audit logs so false positives can be released. In short: combine token/timestamp checks, server-side rate limits, content heuristics and adaptive challenges, monitor results, and iterate. This layered approach balances usability with robust anti‑spam protection.

Recommended Answers

All 3 Replies

Member Avatar for IIM

1)You can use captcha to stop bots from posting data into your thread.....
2)Use session for session if user is registered and once user post it,just set a session value to "some value" and before posting check the value of this session variable.

commented: good answer +5
Member Avatar for reganstar

There is more than one solution to the security issues with the contact form:
- captcha, as previously said (or another alternative, such as checkboxes to tick in order to prove the user is human)
- a script that will limit the number of acceptable submissions from the same IP per time unit. If you are on Asp.Net, this may help: http://www.asp.net/ajaxLibrary/AjaxControlToolkitSampleSite/NoBot/NoBot.aspx

Member Avatar for nielsep

You could also do this :
1) make a captcha, like allready said.
2) make a ekstra "Submit" button... which i guess many "Spambots" jump to.
3) duplicate your form code.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.