CAPTCHA dla TYPO3

Dlaczego decyzja o CAPTCHA nie jest pytaniem technicznym, tylko pytaniem o ochronę danych

CAPTCHA brzmi jak trywialna decyzja: zabezpieczyć formularz przed botami, zainstalować rozszerzenie, gotowe. W praktyce jest to pytanie, którą usługę się osadza, jaką zgodę się generuje i jaki współczynnik konwersji się akceptuje. Dla TYPO3 istnieje kilkanaście podejść, które dzielą się na trzy grupy: widoczne CAPTCHA z zadaniem wizualnym, niewidoczne analizy zachowań jak reCAPTCHA v3 i czysto serwerowe metody bez interakcji użytkownika jak honeypoty lub rate-limiting. Właściwy wybór zależy mniej od siły botów, a bardziej od sytuacji regulacyjnej i grupy docelowej formularza.

Typowe scenariusze zastosowania

Dostawca oprogramowania B2B prowadzi formularz kontaktowy z około 300 prawdziwymi zapytaniami miesięcznie i około 8 000 zgłoszeń od botów. Dostawca już używa Google Analytics, ma działające rozwiązanie zgody i nie traci podstawy prawnej, gdy wbuduje reCAPTCHA v3. W tym przypadku rozwiązanie niewidoczne jest skuteczne: boty są blokowane za kulisami, prawdziwi użytkownicy niczego nie widzą, współczynnik konwersji pozostaje stabilny. Zgoda i tak przychodzi przez istniejący baner zgody.

Administracja gminna z formularzami online dla spraw obywateli ma sytuację odwrotną: Google nie może być osadzone, baner zgody ma być minimalny, a formularz musi działać również bez JavaScript. Tu reCAPTCHA od razu odpada. Kombinacja honeypot plus rate-limiting na reverse proxy plus prosty test arytmetyczny w formularzu wyłapuje 95 procent botów, nie wymaga zewnętrznego zasobu i nie generuje obowiązku zgody.

Trzecim przypadkiem jest instytucja edukacyjna z silnie zróżnicowaną grupą użytkowników: studenci, wykładowcy, kandydaci zewnętrzni, w części z niepełnosprawnością wzrokową. Tu dostępność jest ważniejsza niż jakikolwiek zysk bezpieczeństwa, a czysto wizualne CAPTCHA jest problematyczne. Rozwiązaniem jest konfiguracja hCaptcha z aktywnym trybem dostępności lub instancja sr_freecap z alternatywą audio, uzupełniona o pełne opisy zgodne ze standardem WCAG.

Architektura techniczna: trzy kategorie, trzy wzorce integracji

Widoczne CAPTCHA jak sr_freecap lub hCaptcha pracują według mechanizmu request-response: rozszerzenie generuje lub pobiera zadanie, pokazuje je użytkownikowi, a przy wysłaniu wprowadzenie jest walidowane po stronie serwera. W TYPO3 osadzenie odbywa się przez walidator w Form Framework, przez rozszerzenie ViewHelper Fluid lub przy Powermail przez plugin pola CAPTCHA. Wyzwaniem technicznym jest synchronizacja sesji i integracja w istniejące szablony Fluid.

Niewidoczne CAPTCHA jak reCAPTCHA v3 obliczają score między 0 a 1, który opisuje prawdopodobieństwo, że żądanie jest ludzkie. Score przychodzi jako dodatkowe pole z submit formularza, a rozszerzenie na podstawie konfigurowalnego progu decyduje, czy zgłoszenie zostanie zaakceptowane czy odrzucone. Dużą zaletą jest, że użytkownik niczego nie zauważa, wadą jest nieuniknione przesłanie danych do Google.

Rozwiązania oparte na honeypot pracują bez logiki klienckiej: niewidoczne pole wprowadzania jest dodawane do formularza HTML, ukryte przez CSS lub tabindex=-1. Ludzie go nie wypełniają, boty robią to bardzo często, a po stronie serwera każde zgłoszenie z wypełnionym honeypotem jest odrzucane. Uzupełnione o rate-limiting na bazie IP i weryfikowalny odstęp czasu między załadowaniem strony a submit, blokuje to większość prostych botów bez denerwowania choćby jednego użytkownika.

Częste problemy i rozwiązania

Pierwszy problem to sam wybór: zespoły odruchowo sięgają po reCAPTCHA, bo jest znane i darmowe, i przeoczają obowiązek zgody. Porządna decyzja wymaga krótkiej oceny: jaka infrastruktura zgody istnieje? Jaki krąg użytkowników ma obsługiwać formularz? Jak duże jest faktyczne obciążenie botami? Gosign przeprowadza tę ocenę w ramach krótkiego audytu i rekomenduje dla każdego formularza właściwą metodę, zamiast forsować jednolite rozwiązanie.

Drugi problem to kombinacja kilku mechanizmów ochrony. Kto stosuje równolegle honeypot, CAPTCHA i rate-limiting, tworzy redundancję, ale też źródła błędów: legalny użytkownik zawodzi przy jednym z trzech kroków i traci zaufanie do formularza. Pragmatyczna odpowiedź to stopniowanie metod i aktywowanie najbardziej kosztownej ochrony tylko przy podejrzanym zachowaniu, na przykład pokazanie CAPTCHA dopiero wtedy, gdy rozpoznanie honeypot już zareagowało lub gdy w krótkim czasie wpłynęło kilka zgłoszeń z tego samego IP.

Trzeci temat to monitoring. Zespoły instalują ochronę i zapominają, że skuteczność spada, gdy tylko boty rozwiną dopasowane wzorce zachowań. Skuteczna konfiguracja CAPTCHA loguje współczynnik spamu i współczynnik fałszywych pozytywów oraz aktualizuje progi, gdy liczby się zmieniają. Gosign konfiguruje ten monitoring w ramach integracji rozszerzenia i dostarcza comiesięczną analizę, dzięki czemu widać, kiedy zmiana dostawcy lub dopasowanie staje się konieczne.

Migracja i kompatybilność wersji

W TYPO3 v12 i v13 Form Framework jest centralnym punktem integracji dla rozwiązań CAPTCHA. Rozszerzenia, które jeszcze opierają się na starym FormBuilderze lub typie mailform z czasów core, muszą przy upgrade zostać przebudowane na nowy framework, co z reguły wymusza również ponowny wybór podejścia CAPTCHA. Powermail pozostaje popularną alternatywą i dostarcza własne typy pól CAPTCHA, które są utrzymywane równolegle.

Kto migruje z reCAPTCHA na rozwiązanie przyjazne RODO, oszczędza nie tylko obowiązek zgody, ale często też zyskuje czas ładowania: skrypt reCAPTCHA ma kilkaset kilobajtów i jest doładowywany przez każdą stronę zawierającą formularz. Konfiguracja honeypot radzi sobie bez zewnętrznego skryptu. Gosign wielokrotnie towarzyszył takim migracjom i dostarcza w zależności od modelu operacyjnego albo czystą konfigurację honeypot, albo kombinację z lokalnym zadaniem arytmetycznym, które dla ludzi jest trywialne, a dla botów stanowi zauważalną przeszkodę.