CAPTCHA-ul există – dar nu protejează nimic

Mulți proprietari de site-uri adaugă un CAPTCHA la formularul de contact, văd apărând mica insignă sau caseta de bifat și consideră problema spamului rezolvată. Apoi gunoiul continuă să sosească. Adesea, CAPTCHA-ul în sine este în regulă – doar că nu este conectat la nimic care ar putea opri un bot. Acest articol prezintă modurile tipice în care reCAPTCHA, hCaptcha și Cloudflare Turnstile ajung simple decorațiuni și cum vă puteți verifica propriile formulare.

Unde are loc de fapt protecția

Toate cele trei servicii funcționează pe același principiu. Un script din browser își efectuează verificările și îi predă formularului un token – un șir scurt care spune „acest vizitator a trecut”. Tokenul călătorește împreună cu trimiterea formularului către serverul dumneavoastră. Abia acolo are loc decizia reală: serverul dumneavoastră trimite tokenul împreună cu o cheie secretă către furnizor și primește un răspuns – succes sau eșec, iar pentru reCAPTCHA v3 și un scor. Dacă lipsește orice verigă din acest lanț, widgetul arată în continuare perfect normal, dar un bot care trimite direct către handlerul formularului trece nestingherit.

Cheia de test care lasă totul să treacă

Google, hCaptcha și Cloudflare publică chei de test speciale, astfel încât dezvoltatorii să poată rula teste automate fără a rezolva puzzle-uri. Cu secretul de test corespunzător, verificarea reușește întotdeauna – acesta este tot rostul lor. Ele sunt destinate mediilor locale și de staging, dar supraviețuiesc regulat trecerii în producție: un dezvoltator le inserează în timpul dezvoltării, site-ul intră online și nimeni nu le mai înlocuiește. reCAPTCHA afișează cel puțin în widget o notificare că este destinat doar testării, dar la o configurare invizibilă aproape nimeni nu se uită. Dacă atât cheia de site de test, cât și secretul de test sunt active, fiecare trimitere trece, fie că provine de la un om, fie de la un bot; dacă doar cheia de site este o cheie de test, verificarea eșuează în schimb, iar mesajele reale pot fi respinse.

Un token pe care nu îl verifică nimeni

Al doilea caz clasic este un server care nu întreabă niciodată furnizorul. Widgetul rulează, un token este creat și trimis, iar apoi handlerul formularului pur și simplu îl ignoră. Surse tipice sunt formularele scrise manual, fragmentele de cod copiate care acoperă doar partea de browser și setările de plugin configurate pe jumătate. O rudă apropiată: serverul apelează serviciul de verificare, dar verifică doar dacă cererea a reușit, nu și ce spune răspunsul. Sau pragul de scor pentru reCAPTCHA v3 este setat la 0, ceea ce acceptă orice scor pe care îl poate returna serviciul. Unele handlere „eșuează deschis”: dacă tokenul lipsește sau verificarea eșuează, acceptă oricum mesajul – iar un bot pur și simplu omite tokenul.

Când widgetul nu se încarcă niciodată cu adevărat

Alte configurări greșite strică în schimb partea de browser. Dacă cheia de site nu este înregistrată pentru domeniu – tipic după o mutare de pe staging în producție, o schimbare de domeniu sau un subdomeniu nou –, furnizorul refuză să emită tokenuri și afișează o eroare în widget sau în consola browserului. După o schimbare a temei sau o actualizare a unui plugin, marcajul widgetului poate fi încă în pagină, în timp ce scriptul care îl pune în funcțiune a dispărut. Un instrument de consimțământ pentru cookie-uri poate avea același efect dacă blochează scriptul CAPTCHA până când vizitatorul își dă acordul. Ce se întâmplă mai departe depinde de server: dacă acesta insistă pe un token valid, vizitatorii reali nu mai pot trimite mesaje și nimeni nu observă solicitările pierdute; dacă nu insistă, boții trec liber.

Alte două cazuri sunt ușor de trecut cu vederea. La reCAPTCHA v3, insigna din colț arată doar că scriptul este încărcat undeva pe pagină – poate de temă sau de un alt plugin –, în timp ce integrarea în pluginul de formulare propriu-zis este dezactivată. În plus, pluginurile de cache pot stoca o pagină împreună cu un token încorporat în HTML. Tokenurile CAPTCHA sunt valabile doar câteva minute și pot fi verificate o singură dată, așa că un token din cache eșuează pentru vizitatorii reali; „remedierea” tentantă de a dezactiva verificarea elimină discret protecția.

O scurtă autoverificare

1. 1Deschideți pagina formularului într-o fereastră privată, deschideți instrumentele pentru dezvoltatori ale browserului și căutați în consolă erori de la scriptul CAPTCHA.
2. 2Verificați că widgetul apare efectiv – o dată înainte și o dată după acceptarea bannerului de cookie-uri – și că formularul nu poate fi trimis cât timp widgetul lipsește.
3. 3În consola de administrare a furnizorului, verificați că cheia de site include domeniul dumneavoastră live (inclusiv variante precum www) și că cheile din pluginul de formulare sau din cod corespund acesteia – nu chei din documentație sau dintr-o configurare de staging.
4. 4În setările pluginului de formulare, asigurați-vă că integrarea CAPTCHA este activată pentru acest formular anume; pentru reCAPTCHA v3, verificați că pragul de scor este peste 0.
5. 5Dacă aveți acces la cod, găsiți verificarea de pe server și verificați că aceasta respinge trimiterea atunci când răspunsul este negativ sau tokenul lipsește.
6. 6Excludeți pagina formularului de la cache-ul pentru pagini întregi sau asigurați-vă că tokenul este creat din nou în browser.
7. 7Trimiteți un mesaj de test real și verificați că sosește; repetați verificarea după modificări ale temei, ale pluginurilor sau ale instrumentului de consimțământ.

Un CAPTCHA este un strat, nu întreaga protecție. Combinat cu un câmp honeypot, o verificare a timpului și filtrare pe server, o configurare greșită într-un loc nu lasă formularul complet deschis. Dacă doriți o imagine rapidă a stadiului în care se află formularele dumneavoastră, introduceți domeniul pe formexposed.com – raportul arată dacă părțile configurării CAPTCHA vizibile din exterior sunt în regulă.