a écrit :
QuentinC : j'avais lu quelque part qu'il valait mieux ne pas mettre une classe explicite (comme hidden, honeypot, etc) pour cacher ces champs. Il vaux mieux les faire passer pour des champs ordinaires en leur donnant un nom de classe comme par exemple : name, phone, etc.
Et ne pas hésitez à mettre ce champ intercalé entre d'autres champs. Histoire qu'il ne paraisse pas louche en tout dernier dans le code HTML.
Dans mon cas il est avant le bouton submit. Pour le nom de classe je ne pense pas que ça change grand chose.
L'autre truc utile que je fais outre le champ caché, c'est l'anti CSRF: un champ avec un nom et une valeur random quand change à chaque fois qu'on recharge la page, et si le champ n'est pas présent dans $_POST ou pas avec la bonne valeur, adieu.
Ca oblige le bot ou l'humain à parser la page du formulaire, et ça c'est quelque chose qui le fait ch***.
ON peut pousser le vice plus loin en faisant en sorte que plus aucun nom de champ ne soit constant.
En fait, toutes ces solutions en arrêtent une partie, et c'est en les combinant toutes qu'on obtient le meilleur résultat à mon avis. Le CAPTCHA image et/ou son par contre, ça ennuie presque plus les utilisateurs que les bots maintenant... Les OCR et les reconnaissances vocales commencent à être tellement bons qu'il faut vraiment faire quelque chose de distordu pour les berner, au point qu'on doive s'y reprendre à 5 fois pour y arriver et encore.
