CAPTCHA jest na stronie – ale niczego nie chroni

Wielu właścicieli stron dodaje CAPTCHA do formularza kontaktowego, widzi, że pojawia się mała plakietka albo pole wyboru, i uznaje problem spamu za rozwiązany. A potem śmieci i tak przychodzą. Często sama CAPTCHA działa poprawnie – tyle że nie jest podłączona do niczego, co mogłoby zatrzymać bota. W tym wpisie omawiamy typowe sytuacje, w których reCAPTCHA, hCaptcha i Cloudflare Turnstile stają się zwykłą ozdobą, i pokazujemy, jak sprawdzić własne formularze.

Gdzie naprawdę powstaje ochrona

Wszystkie trzy usługi działają na tej samej zasadzie. Skrypt w przeglądarce przeprowadza swoje testy i przekazuje formularzowi token – krótki ciąg znaków, który mówi: „ten odwiedzający przeszedł weryfikację”. Token trafia razem z formularzem na Twój serwer. Dopiero tam zapada właściwa decyzja: serwer wysyła token wraz z tajnym kluczem do dostawcy i dostaje odpowiedź – sukces lub porażkę, a w przypadku reCAPTCHA v3 także wynik punktowy. Jeśli brakuje któregokolwiek ogniwa tego łańcucha, widżet nadal wygląda zupełnie normalnie, ale bot, który wysyła dane bezpośrednio do skryptu obsługującego formularz, przechodzi bez przeszkód.

Klucz testowy, który przepuszcza wszystko

Google, hCaptcha i Cloudflare publikują specjalne klucze testowe, żeby programiści mogli uruchamiać testy automatyczne bez rozwiązywania zagadek. W parze z odpowiadającym im testowym kluczem tajnym weryfikacja zawsze kończy się sukcesem – po to właśnie istnieją. Są przeznaczone do środowisk lokalnych i testowych, ale regularnie przeżywają przeprowadzkę na produkcję: ktoś wkleja je podczas budowy strony, strona startuje i nikt ich nie podmienia. reCAPTCHA pokazuje co prawda w widżecie informację, że służy tylko do testów, ale przy niewidocznej integracji mało kto to zauważa. Jeśli testowy klucz witryny i testowy klucz tajny działają razem, przechodzi każde zgłoszenie, czy to od człowieka, czy od bota; jeśli testowy jest tylko klucz witryny, weryfikacja się nie udaje – i odrzucane mogą być prawdziwe wiadomości.

Token, którego nikt nie sprawdza

Drugi klasyk to serwer, który nigdy nie pyta dostawcy. Widżet działa, token powstaje i jest wysyłany, a skrypt formularza po prostu go ignoruje. Typowe źródła to formularze pisane ręcznie, skopiowane fragmenty kodu obejmujące tylko część w przeglądarce i niedokończone ustawienia wtyczek. Bliski krewny: serwer co prawda odpytuje usługę weryfikacji, ale sprawdza tylko, czy zapytanie się powiodło, a nie, co jest w odpowiedzi. Albo próg wyniku dla reCAPTCHA v3 ustawiono na 0, co oznacza akceptację każdej wartości, jaką usługa może zwrócić. Niektóre skrypty w razie wątpliwości przepuszczają: jeśli tokenu brakuje albo weryfikacja się nie uda, wiadomość i tak zostaje przyjęta – a bot po prostu pomija token.

Gdy widżet nigdy porządnie się nie ładuje

Inne błędy konfiguracji psują z kolei część działającą w przeglądarce. Jeśli klucz witryny (site key) nie jest zarejestrowany dla danej domeny – typowo po przejściu ze środowiska testowego na produkcję, po zmianie domeny albo przy nowej subdomenie – dostawca nie wydaje tokenów i pokazuje błąd w widżecie lub w konsoli przeglądarki. Po zmianie motywu albo aktualizacji wtyczki znaczniki widżetu mogą zostać na stronie, choć skrypt, który go uruchamia, zniknął. Narzędzie do zgód na cookies może mieć ten sam skutek, jeśli blokuje skrypt CAPTCHA, dopóki odwiedzający nie wyrazi zgody. Co dalej, zależy od serwera: jeśli wymaga ważnego tokenu, prawdziwi odwiedzający nie mogą już wysyłać wiadomości i nikt nie zauważa utraconych zapytań; jeśli nie wymaga, boty przechodzą swobodnie.

Dwa kolejne przypadki łatwo przeoczyć. W reCAPTCHA v3 plakietka w rogu pokazuje tylko, że skrypt jest gdzieś na stronie wczytywany – może przez motyw albo inną wtyczkę – podczas gdy integracja w samej wtyczce formularza jest wyłączona. A wtyczki do cache’owania mogą zapisać stronę razem z tokenem osadzonym w HTML. Tokeny CAPTCHA są ważne tylko kilka minut i można je zweryfikować tylko raz, więc token z cache zawodzi u prawdziwych odwiedzających; kusząca „naprawa” w postaci wyłączenia weryfikacji po cichu usuwa ochronę.

Krótki test na własną rękę

1. 1Otwórz stronę z formularzem w oknie prywatnym, włącz narzędzia deweloperskie przeglądarki i poszukaj w konsoli błędów skryptu CAPTCHA.
2. 2Sprawdź, czy widżet naprawdę się pojawia – raz przed akceptacją banera cookies i raz po niej – i czy bez widżetu formularza nie da się wysłać.
3. 3W panelu administracyjnym dostawcy sprawdź, czy klucz witryny obejmuje Twoją domenę produkcyjną (łącznie z wariantami takimi jak www) i czy klucze we wtyczce formularza lub w kodzie są z nim zgodne – a nie pochodzą z dokumentacji czy ze środowiska testowego.
4. 4W ustawieniach wtyczki sprawdź, czy integracja CAPTCHA jest włączona właśnie dla tego formularza; przy reCAPTCHA v3 upewnij się, że próg wyniku jest wyższy niż 0.
5. 5Jeśli masz dostęp do kodu, znajdź weryfikację po stronie serwera i sprawdź, czy odrzuca wiadomość, gdy odpowiedź jest negatywna albo brakuje tokenu.
6. 6Wyłącz stronę z formularzem z cache’owania całych stron albo zadbaj o to, by token powstawał na świeżo w przeglądarce.
7. 7Wyślij prawdziwą wiadomość testową i sprawdź, czy dotarła; powtarzaj test po każdej zmianie motywu, wtyczek lub narzędzia do zgód.

CAPTCHA to jedna warstwa, a nie cała ochrona. W połączeniu z polem typu honeypot, sprawdzaniem czasu wypełnienia i filtrowaniem po stronie serwera błąd w jednym miejscu nie zostawia formularza otwartego na oścież. Jeśli chcesz szybko zobaczyć, jak wypadają Twoje formularze, wpisz swoją domenę na formexposed.com – raport pokaże, czy widoczna z zewnątrz część Twojej konfiguracji CAPTCHA jest w porządku.