How to prevent robots from automatically filling up a form?

Question

I'm trying to come up with a good enough anti-spamming mechanism to prevent automatically generated input. I've read that techniques like captcha, 1+1=? stuff work well, but they also present an extra step impeding the free quick use of the application (I'm not looking for anything like that please).

I've tried setting some hidden fields in all of my forms, with display: none; However, I'm certain a script can be configured to trace that form field id and simply not fill it.

Do you implement/know of a good anti automatic-form-filling-robots method? Is there something that can be done seamlessly with HTML AND/OR server side processing, and be (almost) bulletproof? (without JS as one could simply disable it).

I'm trying not to rely on sessions for this (i.e. counting how many times a button is clicked to prevent overloads).

Caroncarotene

Thanks for not wanting captcha solutions! IMO, form spam is a problem for site owners and preventing it isn't a burden the user should bear. There are far too many alternative ways we can address spam on the site end, as evidenced by the replies here. Methods requiring user interaction should only be used by the lazy or the novice. – Handwriting

There is an an alternative CAPTCHA that is only triggered on suspicion, that allows normal users to submit but stops spam. – Fantinlatour

Starred and upvoted, esp. because of what Mike said. Accessibility and the WCAG (Web Content Accessibility Guidelines) are another reason to avoid CAPTCHA - even when there's a audio workaround, that helps only some disabled folks. – Coprolalia

Answer 1

An easy-to-implement but not fool-proof (especially on "specific" attacks) way of solving anti-spam is tracking the time between form-submit and page-load.

Bots request a page, parse the page and submit the form. This is fast.

Humans type in a URL, load the page, wait before the page is fully loaded, scroll down, read content, decide wether to comment/fill in the form, require time to fill in the form, and submit.

The difference in time can be subtle; and how to track this time without cookies requires some way of server-side database. This may be an impact in performance.
Also you need to tweak the threshold-time.

History

Thanks! this is a great idea, and close to what I was looking for. – Caroncarotene

Watch out if you want to allow end users to use automatic form fillers such addons.mozilla.org/en-US/firefox/addon/1882 that may allow very fast submission. As well as captcha any thing annoying the final user is generally not good, and especially when preventing a person in a hury from going (very) fast. – Nutty

Good point, but it all depends on the context. If the form is a login-form, I completely agree with you. But why disable login from bots? If the context is a comment box, like this one on StackOverflow, I know for sure: if you use auto-fill on a comment box then you are a spammer. Note that if you use auto-fill for signatures, you still require time to actually type content. – History

Note that SO does something like this. Edit a comment to fast or too many times in a row and you will get presented with the "Are you a human?" page. – Calpac

Hackers won't always request the form. Sometimes, a carefully crafted URL (using GET or POST) will be sufficient to post the form multiple times with little effort. – Lieberman

@History I am trying to implement the same but have some problems #20782173 – Tegantegmen

@History What do you mean by tweak the threshold-time ? – Leone

Implement this with captcha. If the form was submitted too fast, present a captcha to let genuine users through. – Galliwasp

Tried this, but it isn't a good idea at all. When the user fills the form, and receives an error, the correction of the error may take several seconds (eg. correcting the e-mail address). Upon the second submit attempt the form is already completed and it is submitted again in short time. Also there are autofill browser extensions which again will produce false positives. – Mitch

This is not a great idea. A bot could easily implement a delay, or the user could user auto form fillers. – Boser

Answer 2

I actually find that a simple Honey Pot field works well. Most bots fill in every form field they see, hoping to get around required field validators.

http://haacked.com/archive/2007/09/11/honeypot-captcha.aspx

If you create a text box, hide it in javascript, then verify that the value is blank on the server, this weeds out 99% of robots out there, and doesn't cause 99% of your users any frustration at all. The remaining 1% that have javascript disabled will still see the text box, but you can add a message like "Leave this field blank" for those such cases (if you care about them at all).

(Also, noting that if you do style="display:none" on the field, then it's way too easy for a robot to just see that and discard the field, which is why I prefer the javascript approach).

Prolate

Do you think bots actually go through the css file and figure it's display:none; ? I really rather not use a JS-based solution, since it can be easily disabled. – Caroncarotene

It seems to be an old solution for webmasters including tons of non pertinent key words in order to boost their webranking. I think search crawler bots such google ones can figure it's display:none. Why would other bots not able to do that ? – Nutty

The bot would have to execute javascript, that's the point. Gal - for the tiny tiny percentage of your users with javascript turned off, you simply have a label that says "Leave this blank". No harm done. – Prolate

I've used this technique now on two sites that were getting hammered and bot signups are now zero 0 on both. It won't help against targeted attacks, but most are just looking for exploits or for spamming anyway. – Seniority

Small point here: to get around the JS issue, just use CSS to position your honeypot input above the page top - this way it will be ok to have js disabled, and to get around it the bot will have to be able to parse CSS absolute positioning and make a common sense decision on whether it's a honeypot or not. a little more bullet-proof this way :) – Plasticity

@jammypeach or more simply, display: none – Consumer

@alexy13 yes it's more simple but as noted in the answer, it's also alot easier for a bot to figure out what you're trying to do, just test for one CSS property. If, however, you use the absolute positioning strategy, the bot has to parse all of your positioning rules and the rules of most of the element's parents to be able to figure out if the input would be visible or not, and then figure out whether or not to act on that information - which is all more trouble than it's worth for most (if not all) bots. – Plasticity

I know this is a late comment but a site I am working on used the display 'display: none' method and is now receiving spam so the bot can find it. Im just in the process of testing other ways of doing it like setting the input off the screen rather than hiding it. – Atween

As silly as it sounds I created honey pot input and simply made it type="hidden". All the dumb robots fall for it and no spam at all. I'm having trouble understanding why everyone goes with captcha which most of the time gives horrible user experience. My vote definitely goes for honey pots. – Blacklist

I've been using this approach several months now and it works just fine, Easiest anti-bot implementation i know. – Hesitancy

@jammypeach This css-tricks.com/places-its-tempting-to-use-display-none-but-dont For visually hidding elements without display:none; – Hesitancy

@SanBluecat yes it's the same strategy I've advocated due to the disadvantages of using display:none, but there are a couple of different approaches there, thanks for the link. – Plasticity

One further suggestion here would be to position the field beneath another absolutely positioned section of the screen using the z-order - that way it's still within the visible bounds, but not visible to the user. You could also use tab key prevention so the user can't accidentally tab to the hidden control. Belt and braces! – Cuesta

These methods only stop general spam bots, which crawl internet and spam every form, if a bot is made specifically for your form, by a human, it will be useless. – Fantinlatour

Answer 3

What if - the Bot does not find any form at all?

3 examples:

1. Insert your form using AJAX

• If you are OK with users having JS disabled and not being able to see/ submit a form, you can notify them and have them enable Javascript first using a noscript statement:

<noscript>
  <p class="error">
    ERROR: The form could not be loaded. Please enable JavaScript in your browser to fully enjoy our services.
  </p>
</noscript>

• Create a form.html and place your form inside a <div id="formContainer"> element.

• Inside the page where you need to call that form use an empty <div id="dynamicForm"></div> and this jQuery: $("#dynamicForm").load("form.html #formContainer");

2. Build your form entirely using JS

// THE FORM
var $form = $("<form/>", {
  appendTo : $("#formContainer"),
  class    : "myForm",
  submit   : AJAXSubmitForm
});

// EMAIL INPUT
$("<input/>",{
  name        : "Email", // Needed for serialization
  placeholder : "Your Email",
  appendTo    : $form,
  on          : {        // Yes, the jQuery's on() Method 
    input : function() {
      console.log( this.value );
    }
  }
});

// MESSAGE TEXTAREA
$("<textarea/>",{
  name        : "Message", // Needed for serialization
  placeholder : "Your message",
  appendTo    : $form
});

// SUBMIT BUTTON
$("<input/>",{
  type        : "submit",
  value       : "Send",
  name        : "submit",
  appendTo    : $form
});

function AJAXSubmitForm(event) {
  event.preventDefault(); // Prevent Default Form Submission
  // do AJAX instead:
  var serializedData = $(this).serialize();
  alert( serializedData );
  $.ajax({
    url: '/mail.php',
    type: "POST",
    data: serializedData,
    success: function (data) {
      // log the data sent back from PHP
      console.log( data );
    }
  });
}

.myForm input,
.myForm textarea{
  font: 14px/1 sans-serif;
  box-sizing: border-box;
  display:block;
  width:100%;
  padding: 8px;
  margin-bottom:12px;
}
.myForm textarea{
  resize: vertical;
  min-height: 120px;
}

<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<div id="formContainer"></div>

3. Bot-bait input

• Bots like (really like) saucy input elements like:

<input 
  type="text"
  name="email"
  id="email"
  placeholder="Your email"
  autocomplete="nope"
  tabindex="-1"

They wll be happy to enter some value such as
`[email protected]`

• After using the above HTML you can also use CSS to not display the input:

input[name=email]{ /* bait input */
  /* do not use display:none or visibility:hidden
     that will not fool the bot*/
  position:absolute;
  left:-2000px;
}

• Now that your input is not visible to the user expect in PHP that your $_POST["email"] should be empty (without any value)! Otherwise don't submit the form.
• Finally,all you need to do is create another input like <input name="sender" type="text" placeholder="Your email"> after (!) the "bot-bait" input for the actual user Email address.

Acknowledgments:

Developer.Mozilla - Turning off form autocompletition
StackOverflow - Ignore Tabindex

Fare

Could a legitimate user's browser potentially see the bait input field as an email field and autofill it automatically when the user chooses to autofill the rest of the form? The user wouldn't see a field far off screen had been filled, and they would still look like a bot. – Rattray

I suspect autocomplete=nope would default to on ;-) MDN: input#attr-autocomplete – Lentz

@Lentz it doesn't matters, it's a bot bait input. You can write autocomplete="oh sunny day" for that matter. – Fare

@RokoC.Buljan creative anti-bot solutions, thanks fors sharing – Hexaemeron

Answer 4

What I did is to use a hidden field and put the timestamp on it and then compared it to the timestamp on the Server using PHP.

If it was faster than 15 seconds (depends on how big or small is your forms) that was a bot.

Hope this help

Debunk

Good idea, however, I'd set the limit to about 3 to 5 seconds to allow fast/power users. I use this same approach, and setting a limit on my forms to 3 seconds filtered out 99% of the bots. – Apace

@Debunk Do you mean something like: 1) on page load with php get server time and create session. 2) user or bot fills form, clicks Submit, with $.post send all to external php file. 3) in external php again get server time and compare with session time? – Radiobroadcast

Answer 5

A very effective way to virtually eliminate spam is to have a text field that has text in it such as "Remove this text in order to submit the form!" and that text must be removed in order to submit the form.

Upon form validation, if the text field contains the original text, or any random text for that matter, do not submit the form. Bots can read form names and automatically fill in Name and Email fields but do not know if they have to actually remove text from a certain field in order to submit.

I implemented this method on our corporate website and it totally eliminated the spam we were getting on a daily basis. It really works!

Stele

Interesting, do you know if it is more effective than the other answers... a hidden textbox or tracking the time it takes to fill the form? – Journalese

This would also catch those users who cannot follow directions, which may not be desired. – Rattray

I like this! Until the bot starts trying different combinations of blank and filled-in fields... best way to test is implement this and scan with one of these: sectoolmarket.com/… – Housetop

Effective so far as the person managing the bot doesn't find out and tweaks the code. – Wellbred

Stopping general spam bots is easy anyways, if it's a targeted bot, CAPTCHA is the only solution – Fantinlatour

Answer 6

How about creating a text field input box the same color as the background which must remain blank. This will get around the problem of a bot reading display:none

Py

Add this as comment please when you get more reputation instead of an answer ;) – Chromosphere

This presents accessibility problems. The honeypot index will not be hidden from users with screen readers. – Ordzhonikidze

I'm a blind user, and I found a form field like this once, and the label above it read: "If you can see this, leave this blank." Very effective IMO. – Certie

Answer 7

http://recaptcha.net/

reCAPTCHA is a free antibot service that helps digitize books

It has been aquired by Google (in 2009):

• https://www.google.com/recaptcha
• https://developers.google.com/recaptcha/

Also see

• https://en.wikipedia.org/wiki/ReCAPTCHA
• https://en.wikipedia.org/wiki/CAPTCHA for more general information

Cellarage

As a user I find recaptcha to be hard to figure out often times. Some of the words are so hard to read, that you end up having to try 3 or 4 times. Although this definitely will help with the robots problem. – Servomechanism

What Brian said and: yro.slashdot.org/story/10/03/02/0135238/… – Nelrsa

I've found myself on this page because CAPTCHA / reCAPTCHA doesn't currently stop bot form submission. This is 5 years later and it's a new technique than when this answer was given – Thickening

I'm amazed why this answer does not have more upvotes. whether or not the user like, this is a great solution. Especially, if it is only used for the registration form. – Earthen

These days recaptcha starts as a simple checkbox, perhaps it's not as painful as it used to be? ... – Necessitous

link is invalid. – Sled

reCaptcha also (by design) leaks data to google. Not a good look for privacy. – Inkerman

Answer 8

Many of those spam-bots are just server-side scripts that prowl the web. You can combat many of them by using some javascript to manipulate the form request before its sent (ie, setting an additional field based on some client variable). This isn't a full solution, and can lead to many problems (eg, users w/o javascript, on mobile devices, etc), but it can be part of your attack plan.

Here is a trivial example...

<script>
function checkForm()
{
    // When a user submits the form, the secretField's value is changed
    $('input[name=secretField]').val('goodValueEqualsGoodClient');

    return true;
}
</script>

<form id="cheese" onsubmit="checkForm">
<input type="text" name="burger">

<!-- Check that this value isn't the default value in your php script -->
<input type="hidden" name="secretField" value="badValueEqualsBadClient">

<input type="submit">
</form>

Somewhere in your php script...

<?php

if ($_REQUEST['secretField'] != 'goodValueEqualsGoodClient')
{
    die('you are a bad client, go away pls.');
}

?>

Also, captchas are great, and really the best defense against spam.

Fireworm

Thanks, though javascript can be easily disabled in any browser, thus annihilating my "anti spam mechanism", so I'm looking for something more global. – Caroncarotene

I may be wrong, but wouldn't this tell every JS-disabled user 'you are a bad client, go away pls.'? – Caroncarotene

Gal, its a trivial example, merely demonstrating how to validate against a request var set by client-side js. – Fireworm

@John Himmelman Captchas are solvable and not necessarily the best defense against spam. There are pay-for-services like anti-captcha.com that will solve form captchas for a low fee. – Presumption

The problem with this approach is that I have seen a lot of bots using PhantomJS. This would allow them to get through. – Certie

@ParhamDoustdar Agreed, I answered this question about a year before PhantomJS was released :(. – Fireworm

Answer 9

I'm surprised no one had mentioned this method yet:

• On your page, include a small, hidden image.
• Place a cookie when serving this image.
• When processing the form submission, check for the cookie.

Pros:

• convenient for user and developer
• seems to be reliable
• no JavaScript

Cons:

• adds one HTTP request
• requires cookies to be enabled on the client

For instance, this method is used by the WordPress plugin Cookies for Comments.

Ator

Wouldn't bots who use stuff like PhantomJS easily get around this? – Certie

As it's a full browser engine, that loads assets and such, yeah that should be possible. Still, I'm not sure it is often used for a spam bot, as it's probably much slower than cURL scripts. – Ator

any reason this would be better than a CSRF token? – Gerstner

a CSRF token won't stop a bot at all. 1st request, GET the form, which includes the token. 2nd request, POST the form, including the token. – Ator

Answer 10

With the emergence of headless browsers (like phantomjs) which can emulate anything, you can't suppose that :

• spam bots do not use javascript,
• you can track mouse events to detect bot,
• they won't see that a field is visually hidden,
• they won't wait a given time before submitting.

If that used to be true, it is no longer true.

If you wan't an user friendly solution, just give them a beautiful "i am a spammer" submit button:

 <input type="submit" name="ignore" value="I am a spammer!" />
 <input type="image" name="accept" value="submit.png" alt="I am not a spammer" />

Of course you can play with two image input[type=image] buttons, changing the order after each load, the text alternatives, the content of the images (and their size) or the name of the buttons; which will require some server work.

 <input type="image" name="random125454548" value="random125454548.png"
      alt="I perfectly understand that clicking on this link will send the
      e-mail to the expected person" />
 <input type="image" name="random125452548" value="random125452548.png"
      alt="I really want to cancel the submission of this form" />

For accessibility reasons, you have to put a correct textual alternative, but I think that a long sentence is better for screenreaders users than being considered as a bot.

Additional note: those examples illustrate that understanding english (or any language), and having to make a simple choice, is harder for a spambot than : waiting 10 seconds, handling CSS or javascript, knowing that a field is hidden, emulating mouse move or emulating keyboard typing, ...

Ventricose

It seems to me that the very fact you have to put the alternate text means that your two image solution is just as susceptible to scripting as the other alternatives. And for the "I am not a spammer" button: can't that be scripted too? – Ratite

@Ratite My answer was that an headless browser can emulate anything : javascript, delays, mouse move, hidden fields, ... The term "beautiful" before my examples was kind of "sarcastic". But those examples illustrate that understanding english, and having to make a simple choice, is harder for a spambot than : waiting 10 seconds, handling CSS or javascript, knowing that a field is hidden, emulating mouse move or emulating keyboard typing, ... – Ventricose

I see your point now. Maybe add last statement "But those examples illustrate..." etc. to your answer. Because that helped me understand what you mean. It seemed at first to be a self contradicting argument that "we can't assume bots can't..." but then list things that we still can't assume bots can't do. But the crux of your point is that your example (having to make a choice on which submit button) is harder --which (now that I understand) is a brilliant answer. +1 – Ratite

Answer 11

A very simple way is to provide some fields like <textarea style="display:none;" name="input"></textarea> and discard all replies that have this filled in.

Another approach is to generate the whole form (or just the field names) using Javascript; few bots can run it.

Anyway, you won't do much against live "bots" from Taiwan or India, that are paid $0.03 per one posted link, and make their living that way.

Nelrsa

I know this answer is nearly 7 years old but I feel like this is worth commenting on. Many bots can be programmed to ignore fields with a style="display:none" to avoid this type of protection. – Metabolize

There are dozens of methods of obscuring inputs, using Javascript, displaying dummy elements on top of them, moving them out of visible area, styling them to blend with background or layout decorations perfectly etc. Randomizing (hashing) input names (and keeping the mapping of hashed=>original in session server-side) will help against using names as hints and manually mapping which inputs are valid. Regardless, there is no defense against manual spam. – Nelrsa

Answer 12

I have a simple approach to stopping spammers which is 100% effective, at least in my experience, and avoids the use of reCAPTCHA and similar approaches. I went from close to 100 spams per day on one of my sites' html forms to zero for the last 5 years once I implemented this approach.

It works by taking advantage of the e-mail ALIAS capabilities of most html form handling scripts (I use FormMail.pl), along with a graphic submission "code", which is easily created in the most simple of graphics programs. One such graphic includes the code M19P17nH and the prompt "Please enter the code at left".

This particular example uses a random sequence of letters and numbers, but I tend to use non-English versions of words familiar to my visitors (e.g. "pnofrtay"). Note that the prompt for the form field is built into the graphic, rather than appearing on the form. Thus, to a robot, that form field presents no clue as to its purpose.

The only real trick here is to make sure that your form html assigns this code to the "recipient" variable. Then, in your mail program, make sure that each such code you use is set as an e-mail alias, which points to whatever e-mail addresses you want to use. Since there is no prompt of any kind on the form for a robot to read and no e-mail addresses, it has no idea what to put in the blank form field. If it puts nothing in the form field or anything except acceptable codes, the form submission fails with a "bad recipient" error. You can use a different graphic on different forms, although it isn't really necessary in my experience.

Of course, a human being can solve this problem in a flash, without all the problems associated with reCAPTCHA and similar, more elegant, schemes. If a human spammer does respond to the recipient failure and programs the image code into the robot, you can change it easily, once you realize that the robot has been hard-coded to respond. In five years of using this approach, I've never had a spam from any of the forms on which I use it nor have I ever had a complaint from any human user of the forms. I'm certain that this could be beaten with OCR capability in the robot, but I've never had it happen on any of my sites which use html forms. I have also used "spam traps" (hidden "come hither" html code which points to my anti-spam policies) to good effect, but they were only about 90% effective.

Toritorie

Answer 13

Another option instead of doing random letters and numbers like many websites do, is to do random pictures of recognizable objects. Then ask the user to type in either what color something in the picture is, or what the object itself is.

All in all, every solution is going to have its advantages and disadvantages. You are going to have to find a happy median between too hard for users to pass the antispam mechanism and the number of spam bots that can get through.

Servomechanism

Good idea. I wouldn't use colour as the criteria though, as this may exclude colourblind users – Irradiance

Yes, good point. Actually a problem with images in general is that they are not accessible, and by making them "accessible" with alt tags, robots can easily figure them out. – Servomechanism

Images are always a bad idea ... the text can barely be read, I faced this issue with other websites – Consequence

This is just captcha with a very small twist that makes is harder for users. Also it is not accessible at all. – Narcotic

Answer 14

the easy way i found to do this is to put a field with a value and ask the user to remove the text in this field. since bots only fill them up. if the field is not empty it means that the user is not human and it wont be posted. its the same purpose of a captcha code.

Wadmal

Answer 15

I've added a time check to my forms. The forms will not be submitted if filled in less than 3 seconds and this was working great for me especially for the long forms. Here's the form check function that I call on the submit button

function formCheck(){
var timeStart; 
var timediff;

$("input").bind('click keyup', function () {
    timeStart = new Date().getTime();          
}); 
 timediff= Math.round((new Date().getTime() - timeStart)/1000);

  if(timediff < 3) { 
    //throw a warning or don't submit the form 
  } 
  else submit(); // some submit function

}

Acapulco

Answer 16

Decided to add another answer, sorry.

We use a combination of two:

1. Honeypot field with name="email" (already mentioned by other answers) just be sure to use a sophisticated way to hide it , like moving off the screen or something. Because bots can detect display:none
2. A hidden field that is set by JavaScript when the user clicks (or focuses if you want to be TAB-friendly) on a required field (wasn't mentioned in other answers)

The 2nd option can even protect from a headless-browser type of spam (using phatnom.js or Selenium) because even JavaScript-bots don't bother actually clicking textboxes.

Blocks 99% of bots.

PS. Make sure to use the focus trick only on fields that are not being filled by password managers like LastPass or 1Passwor.

For the same reasons - mark your honeypot with autocomplete="false" tabindex="-1"

Bedlam

Answer 17

The best solution I've found to avoid getting spammed by bots is using a very trivial question or field on your form.

Try adding a field like these :

• Copy "hello" in the box aside
• 1+1 = ?
• Copy the website name in the box

These tricks require the user to understant what must be input on the form, thus making it much harder to be the target of massive bot form-filling.

EDIT

The backside of this method, as you stated in your question, is the extra step for the user to validate its form. But, in my opinion, it is far simpler than a captcha and the overhead when filling the form is not more than 5 seconds, which seems acceptable from the user point of view.

Pied

As a user, I hate that crap. I get that spam is an issue, but how is it my problem, as a site user? Comment spam is an issue for the site owner, and as such, the user shouldn't take the burden of preventing it. If you walked into a store and were asked to put protective booties over your shoes because they didn't want to mop, what would your thoughts be then? It only takes a few seconds, but it's not your burden to bear. – Handwriting

@Miki spam makes a site owner waste time. Time is money, what I sell will be more expensive for you. Your argument can be easily be used to say that "I do not care that you have to pay rent, I want to pay cost of production +1$. How is you paying rent my problem". When you purchase something you pay for hosting, transportation, time etc. – Narcotic

@Handwriting - It's your problem because you want the form to work (obviously, since you're using it). Machines find even the most obscure sites and will spam tens of thousands of submissions a day, making those forms unusable. So next time you submit a question to a small business using a form on their website and you have to add 9+3 to do it...and ask yourself "why do I have to do this?" your answer can be "because I actually want an answer to my question". – Sleepless

@JimboJonny You completely missed my point. Spam is an issue (like I stated), but there are ways to address it on the backend that don't taint the user experience. I currently have contact forms deployed on dozens (hundreds, even) of websites, and spam is minimal (a few spam messages a month, per form) because I've addressed spam programmatically, not by making users jump through hoops. My point wasn't that spam is not an issue; it IS an issue. My point was that there are ways to address it without fudging with the user's experience. – Handwriting

@JimboJonny Case in point, look at the highest ranked (and accepted) answers on this question. None involve any sort of user input. That's the way spam mitigation should be. – Handwriting

@Handwriting - yikes...so when you've got hundreds of forms on hundreds of websites that rely on a honeypot hidden field and suddenly the more popular bot program makers just add a new feature to detect if a field is hidden via CSS (wouldn't really be that hard) you're going to have, what...a million or so spam messages per hour to suddenly have to clean out and hundreds of websites that are unusable until you get a new solution? I see you like to live dangerously, my friend. – Sleepless

@JimboJonny I never said I rely solely on a honeypot, but there are a combination of similar methods that are effective. You realize I could have written your exact same comment about the user input method above, right? A computer would never be able to provide the answer to a simple math problem... – Handwriting

@Handwriting - Simple math isn't great either (more complex user input is desirable), but it is still a lot harder to build the AI to recognize math on a page and its relevance to a field (that's the hard part). I used the honeypot example, but the idea of these simple yet obscure fixes (like the accepted answer) is what I'm going at. Those answers work SOLELY because that method is not prevalent enough for bot makers to bother spending the couple hours it would take to get around it. It's security through obscurity...which works until it's not obscure anymore and then blows up catastrophically. – Sleepless

@JimboJonny AI like that has been around since the 1960's... which is the reason why virtually all credible captcha type utilities rely on more than just human input. But it's clear you aren't getting my point, so I digress. Keep on thinking that dropping a steaming pile on the user experience is the way to handle something that should (and can) be addressed programmatically. – Handwriting

@Handwriting - The math is not the hard part. Very few can render a page and spatially/linguistically analyze visual relationships reliably across websites to figure out what fields need what from a human perspective. Humans do that innately. That is the main difference between a bot and human. Others can be too easily faked. That is why input methods work so well. On the other hand every non-input method listed on this page I could program a workaround for quite easily, now that I know people are using it. Obscurity was all they had. If you have one that is not so obscurity dependent then share. – Sleepless

Answer 18

Its just an idea, id used that in my application and works well

you can create a cookie on mouse movement with javascript or jquery and in server side check if cookie exist, because only humans have mouse, cookie can be created only by them the cookie can be a timestamp or a token that can be validate

Move

Interesting idea! Have you used this in the real world at all? – Flicker

It won't work. These days spammers are using software that runs in the browser. So they can mimick the user experience which creates the cookie and then run it x number of times using different content that is generated by the software. – Ghost

This wouldn't work if the user was not using a mouse. If your form is set up properly, the user should be able to fill in the entire form using they keyboard. You can tab to the next fields, use space bar to select radio buttons, and use space bar (or enter) when you tab onto the submit button. – Metabolize

Answer 19

In my experience, if the form is just a "contact" form you don't need special measures. Spam get decently filtered by webmail services (you can track webform requests via server-scripts to see what effectively reach your email, of course I assume you have a good webmail service :D)

Btw I'm trying not to rely on sessions for this (like, counting how many times a button is clicked to prevent overloads).

I don't think that's good, Indeed what I want to achieve is receiving emails from users that do some particular action because those are the users I'm interested in (for example users that looked at "CV" page and used the proper contact form). So if the user do something I want, I start tracking its session and set a cookie (I always set session cookie, but when I don't start a session it is just a fake cookie made to believe the user has a session). If the user do something unwanted I don't bother keeping a session for him so no overload etc.

Also It would be nice for me that advertising services offer some kind of api(maybe that already exists) to see if the user "looked at the ad", it is likely that users looking at ads are real users, but if they are not real well at least you get 1 view anyway so nothing loss. (and trust me, ads controls are more sophisticated than anything you can do alone)

Burgenland

Answer 20

I'm thinking of many things here:

1. using JS (although you don't want it) to track mouse move, key press, mouse click
2. getting the referral url (which in this case should be one from the same domain) ... the normal user must navigate through the website before reaching the contact form: PHP: How to get referrer URL?
3. using a $_SESSION variable to acquire the IP and check the form submit against that list of IPs
4. Fill in one text field with some dummy text that you can check on server side if it had been overwritten
5. Check the browser version: http://chrisschuld.com/projects/browser-php-detecting-a-users-browser-from-php.html ... It's clear that a bot won't use a browser but just a script.
6. Use AJAX to send the fields one by one and check the difference in time between submissions
7. Use a fake page before/after the form, just to send another input

Consequence

Could you elaborate on some of these steps valicu2000? Are they still valid in 2020? Thanks. – Jacobs

Answer 21

Actually the trap with display: none works like a charm. It helps to move the CSS declaration to a file containing any global style sheets, which would force spam bots to load those as well (a direct style="display:none;" declaration could likely be interpreted by a spam bot, as could a local style declaration within the document itself).

This combined with other countermeasures should make it moot for any spam bots to unload their junk (I have a guest book secured with a variety of measures, and so far they have fallen for my primary traps - however, should any bot bypass those, there are others ready to trigger).

What I'm using is a combination of fake form fields (also described as invalid fields in case a browser is used that doesn't handle CSS in general or display: none in particular), sanity checks (i. e. is the format of the input valid?), time stamping (both too fast and too slow submissions), MySQL (for implementing blacklists based on e-mail and IP addresses as well as flood filters), DNSBLs (e. g. the SBL+XBL from Spamhaus), text analysis (e. g. words that are a strong indication for spam) and verification e-mails (to determine whether or not the e-mail address provided is valid).

One note on verification mails: This step is entirely optional, but when one chooses to implement it, this process must be as easy-to-use as possible (that is, it should boil down to clicking a link contained in the e-mail) and cause the e-mail address in question to be whitelisted for a certain period of time so that subsequent verifications are avoided in case that user wants to make additional posts.

Fogg

Answer 22

1. I use a method where there is a hidden textbox. Since bots parse the website they probably fill it. Then I check it if it is empty if it is not website returns back.

2. Add email verification. The user receives an email and he needs to click a link. Otherwise discard the post in some time.

Ellisellison

Answer 23

You can try to cheat spam-robots by adding the correct action atribute after Javascript validation. If the robot blocks Javascript they can never submit the form correctly.

HTML

<form id="form01" action="false-action.php">
    //your inputs
    <button>SUBMIT</button>
</form>

JAVASCRIPT

$('#form01 button').click(function(){

   //your Validations and if everything is ok: 

    $('#form01').attr('action', 'correct-action.php').on("load",function(){
        document.getElementById('form01').submit()
    });
})

I then add a "callback" after .attr() to prevent errors.

Mag