Rodzaje zabezpieczeń formularzy - jak nie zwariować i nie odstraszać klientów.

Po raz kolejny, wypełniając formularz, stajesz przed wszechmocnym serwerem i z pokorą zaznaczasz niegroźnie wyglądające pudełeczko.
„Nie jestem robotem” - mówisz pewnie, z nonszalancją i spokojem.

I wtedy zaczyna się rozgrywka.

Czy jesteś w stanie rozpoznać?

• Jak wygląda rower?
• A hydrant?
• A widzisz hydrant tutaj?
• A tu może kawałek roweru?

Klikaj! Klikaj szybciej, człowieku!
Po kilku minutach zaczynasz się zastanawiać, gdzie w życiu popełniłeś błąd.
Czy to jakaś forma pokuty?
Czy to kara za grzechy, o których zapomniałeś wspomnieć na spowiedzi?
Czy tak już musi być?
Czy naprawdę nie da się inaczej?

Cóż, witaj w świecie, gdzie połowa Internetu to boty.

I to nie przesada - według danych z ostatnich lat, ponad 50% całego ruchu w sieci generują automaty.
Niektóre z nich grzecznie indeksują strony, inne spamują, rejestrują konta, wysyłają formularze kontaktowe i próbują Ci sprzedać “lepsze SEO w 24 godziny”.

Efekt? Ludzkość weszła w otwartą wojnę z maszynami (póki co nie jest to skynet), a polem bitwy stał się... formularz kontaktowy.

Każdy checkbox, puzzle, znak drogowy i hydrant to nasz cyfrowy mur obronny.
Szkoda tylko, że czasem bardziej rani użytkownika niż bota.

Bo przecież intencja była dobra: chronić przed spamem, phishingiem i automatycznymi zgłoszeniami.

Tylko że po drodze gdzieś zgubiliśmy człowieka – tego prawdziwego, który chciał po prostu wysłać zapytanie o wycenę strony, a skończył testowany na cierpliwość przez algorytmy Google.

Skąd właściwie wzięło się CAPTCHA?

Historia stara jak sam Internet - czyli moment, w którym człowiek odkrył, że potrafi stworzyć coś, co będzie klikało szybciej od niego.

I tak oto na świat przyszły boty – cudowne programy, które buszują po sieci, indeksują strony, a czasami - z najlepszymi intencjami - wysyłają Ci miliony cudownych ofert na pozycjonowanie, kredyt albo tani hosting w Bangladeszu.

Boty, niczym obietnice polityków, przeszły transformację: od wielkich idei do… no cóż, raczej marnych pomysłów.

Początki botów

Skoro pojawił się problem, trzeba było wymyślić rozwiązanie.
W 1997 roku powstała pierwsza wersja zautomatyzowanego testu Turinga, a w 2003 roku termin CAPTCHA wszedł do powszechnego użycia.

Kiedy Google wkracza do akcji: CAPTCHA

Kilka lat później pojawił się wujek Google.
Zobaczył potencjał, kupił projekt i – oczywiście – ulepszył go dla dobra ludzkości.
Czytaj: przerobił na darmową fabrykę danych do trenowania modeli AI.

Od tej chwili stałeś się bohaterem z przypadku – niezatrudnionym, nieopłacanym, ale niezwykle sumiennym trenerem maszyn.

Pamiętasz te książki w CAPTCHA?

Jeśli masz odpowiedni staż w Internetach, pewnie kojarzysz te rozmazane słowa obok komputerowego napisu.
To nie przypadek. Google w 2009 roku wykorzystało CAPTCHA do cyfrowego przepisywania książek i gazet w ramach projektu Google Books.

W kolejnych latach pojawiły się obrazki – światła, przejścia, hydranty i samochody.
Tak, wtedy uczyłeś autonomiczne auta rozpoznawać świat.
Klikając w rowery, pomagałeś, żeby dzisiejsze Waymo wiedziało, jak Cię ominąć na pasach.
Czegóż się nie zrobi dla tych biednych giga korporacji.

Efekt: frustracja kontra spam

Problem w tym, że zamiast chronić użytkownika, CAPTCHA zaczęła go… karać.
Zamiast wysłanych formularzy - porzucenia.
Zamiast leadów - frustracja.

Formularz to często punkt decydujący o konwersji: kontakt, zamówienie, zapytanie.
A tu nagle staje się testem cierpliwości.

Z drugiej strony - jeśli nie zabezpieczysz się wcale, spam zaleje Ci skrzynkę jak powódź tysiąclecia.

Więc co zrobić, żeby nie zwariować między spamem a użytecznością?
Spokojnie - mam dla Ciebie kilka rozwiązań, które pomogą znaleźć balans.

Honey pot - miód na boty.

Jedna z prostszych, ale zaskakująco skutecznych metod ochrony formularzy.
Stosuję ją jako pierwszą linię obrony i, choć jej zasada działania jest banalna, to w praktyce często wystarcza.
Jej piękno? Całkowita niewidoczność.
Nie przeszkadza użytkownikowi, nie wymaga klikania w hydranty, a mimo to robi robotę.

Jak działa honeypot?

BOT - wypełnia pola, które są dla człowieka niewidoczne, dzięki temu wiadomo, że to właśnie bot. Inaczej pole pozostałoby puste.

Aby to zrozumieć, trzeba spojrzeć na formularz oczami dwóch istot:
człowieka i bota.

Dla człowieka - to proste: pola do wypełnienia, przycisk „Wyślij” i gotowe.
Dla bota - to po prostu kod HTML, który należy “przeżuć”.
Widzi wszystkie pola, niezależnie od tego, czy są ukryte czy nie.
A skoro widzi pole, to je wypełnia - bo przecież po co miałoby być puste?

I tu właśnie czeka pułapka.
Dodajemy niewidoczne pole (np. poprzez display: none lub aria-hidden), którego prawdziwy użytkownik nigdy nie widzi. Nadajemy mu ciekawą nazwę, która brzmi jak ważne pole (elementy wykluczające go z dostępności WCAG - poniżej).
Jeśli zostanie wypełnione - wiadomo, że formularz przesłał bot.

System wtedy blokuje wiadomość lub odrzuca zgłoszenie zanim trafi do skrzynki.
Proste, eleganckie, bez irytujących quizów z rozpoznawaniem hydrantów.

Dlaczego warto?

• Skuteczność: zatrzymuje 70–85% automatów.
• Użyteczność: zero wpływu na UX.
• Wdrożenie: kilka linijek kodu, żadnych zewnętrznych usług.

Honeypot to coś jak klasyczna pułapka na muchy – nikt jej nie widzi, ale działa doskonale. I właśnie za to warto ją lubić.

Honeypot kontra WCAG - czyli gdy dobre intencje się gryzą.

Ok, ale jakie są minusy? No i tutaj dochodzimy do WCAG. Żeby formularz był naprawdę dostępny, każde pole - nawet to ukryte musi spełniać określone zasady.
Problem w tym, że spełniając je, możesz przypadkiem podpowiedzieć botom, że to właśnie… to pole jest pułapką.

Z jednej strony - chcesz być fair wobec użytkowników korzystających z czytników ekranu, z drugiej - nie chcesz, żeby Twój honeypot wyglądał jak strzała.

Aby zachować równowagę, pole honeypota:

• powinno być pominięte przy nawigacji klawiaturą (tabindex="-1" lub inert),
• oraz oznaczone jako niewidoczne dla technologii asystujących (aria-hidden="true").

Dzięki temu użytkownik go nie zauważy, czytnik go nie przeczyta, a Ty możesz dalej spać spokojnie, wiedząc, że nie poświęciłeś dostępności na ołtarzu antyspamu.

Time based validation.

Boty to szybkie bestie. Jak szybko jesteś w stanie wypełnić formularz? Nawet jeśli masz autouzupełnianie, kopiujesz dane z notatnika i klikasz jak Usain Bolt po trzecim espresso - w porównaniu z botem jesteś wolny jak płyty tektoniczne.

I właśnie ta różnica jest kluczem.

Zasada działania tej metody jest prosta:
jeśli formularz zostanie wysłany zbyt szybko po załadowaniu strony - powiedzmy w mniej niż sekundę - można z dużym prawdopodobieństwem założyć, że zrobił to bot, a nie człowiek.

Bo nawet najbardziej napalony klient nie jest w stanie przeczytać etykiety, wpisać imienia, e-maila i kliknąć „Wyślij” w 0,8 sekundy (no chyba że nazywasz się Barry Allen).

To zabezpieczenie działa w tle, bez denerwujących użytkownika elementów.
Nie wymaga puzzli, testów, ani rozpoznawania hydrantów.
Po prostu - mierzy czas reakcji i eliminuje podejrzanie szybkie zgłoszenia.

Dlaczego warto?

• Skuteczność: dobra w połączeniu z honeypotem.
• Użyteczność: zero wpływu na interakcję użytkownika.
• Zastosowanie: dodatkowa warstwa ochrony, która działa bez Twojego udziału.

Proste, niewidoczne i całkiem sprytne - coś jak strażnik, który nie krzyczy, tylko uśmiecha się, gdy złapie intruza na gorącym uczynku.

CAPTCHA, ale bardziej po ludzku.

Po wielu iteracjach, testach i zapewnieniach, że tym razem będzie lepiej, CAPTCHA w końcu zrobiono krok w stronę ludzkiego zachowania.
Z zniekształconych literek i testów z rowerami przeszliśmy do wersji, w której... wystarczy po prostu nic nie robić lub zaznaczyć, że jesteś człowiekiem jeśli automatyczne sprawdzenie z jakiegoś powodu się nie uda.

Nowoczesne systemy, takie jak reCAPTCHA v3 czy Cloudflare Turnstile, analizują zachowanie użytkownika w tle – bez klikania, przesuwania puzzli i zastanawiania się, czy ten pikselowy cień to jeszcze hydrant czy już ciężarówka.

Wystarczy trochę poczekać, formularz sam stwierdza, że jesteś człowiekiem – i gotowe pudełeczko magicznie się zaznacza.

Moja ulubiona pomoc: Cloudflare Turnstile

Turnstile to coś, co wreszcie zrozumiało, że użytkownik nie chce udowadniać swojej biologicznej egzystencji.
Działa w tle, nie wymaga logowania przez Google, nie śledzi użytkownika i nie wysyła mu testów na cierpliwość.

Według Cloudflare, Turnstile blokuje około 90% prób automatycznych zgłoszeń,
a jednocześnie nie psuje użyteczności formularzy – i to właśnie w tym tkwi jego siła.

Nie jest darmowym cudotworem (trzeba poświęcić chwilę na integrację), ale w zamian dostajesz komfort użytkownika i spokój serwera, czyli coś, czego nie da się kupić w abonamencie Google’a.

To rozwiązanie dla tych, którzy chcą bezpieczeństwa, ale nie chcą karać ludzi za to, że chcą do Ciebie napisać.
Bo jeśli Twój formularz przypomina test selekcji NASA, to może czas, żebyś przestał testować użytkowników, a zaczął testować… lepsze zabezpieczenia.

Inne metody (i dlaczego im tu nie poświęcam całej sekcji).

Oczywiście istnieje cały wachlarz innych technik antyspamowych i owszem, niektóre z nich są całkiem sensowne. Powód, dla którego skupiłem się wcześniej na honeypot i time-based jest prosty: chcę proponować rozwiązania, które są:

• sensowne z punktu widzenia użyteczności,
• łatwe do wdrożenia,
• i nie wymagają abonamentu ani dodatkowych usług.

Poniżej szybkie przypomnienie o alternatywach - z krótkim komentarzem, kiedy warto je rozważyć:

1. Akismet (i podobne serwisy antyspamowe) - popularne, solidne, działają „od ręki” w WordPressie. Implementacja prosta, ale darmowe plany mają ograniczenia (zwłaszcza dla stron komercyjnych). Dobre, jeśli chcesz odpuścić sobie część pracy i zapłacić za wygodę.
2. Analiza IP / reputacji / geoblokowanie - sprawdzasz, skąd przyszło zgłoszenie, czy IP ma złą historię, lub blokujesz całe kraje źródłowe. Skuteczne, ale łatwo przesadzić i zablokować klientów. Przydatne przy dużej fali ataków z jednego regionu.
3. Analiza treści (heurystyka) - sprawdzanie, czy treść wygląda jak spam (linki, frazy, podejrzane domeny). Daje dużą elastyczność, ale wymaga dopracowania reguł i testów, żeby nie odcinać wartościowych leadów.
4. Rate limiting (ograniczenie ilości wysyłek na minutę) - proste i skuteczne przeciw botom generującym setki żądań. Minimalny wpływ na UX, świetne jako warstwa dodatkowa.
5. Własne reguły walidacji e-maila / formularza - sprawdzenie formatu, DNS/SMTP check, blacklisty domen. Dobre uzupełnienie, ale nie rozwiązuje wszystkich problemów.
6. Matematyczne zadania / pytania tekstowe - stare, mało eleganckie; łatwe do obejścia dla zaawansowanych botów i często irytujące dla użytkowników (zwłaszcza mobilnych). Używać tylko, gdy brak innych opcji i akceptujesz spadek konwersji.
7. Zaawansowane serwisy behavioral / ML (np. komercyjne systemy oceniające zachowanie) - mocne, „niewidoczne” dla użytkownika, ale kosztowne i wymagają integracji; dobry wybór dla dużych serwisów, gdzie spam oznacza wymierne straty.

Krótkie podsumowanie wyboru.

Zabezpieczenie formularzy przed botami to zawsze balans między użytecznością a bezpieczeństwem. Bo to właśnie na formularzach najczęściej polegamy - i to one potrafią jednym kliknięciem zmienić zainteresowanego klienta w zirytowanego uciekiniera. Zbyt nudne, zbyt długie, zbyt trudne i cyk komentarz w necie.

Dlatego wdrażając zabezpieczenia, warto zaczynać od tych, które w ogóle nie ingerują w komfort użytkownika – takich jak honeypot czy time-based validation.
A dopiero gdy okaże się, że boty przeskoczyły ten poziom (a miałem takie sytuacje w projektach), można dołożyć kolejne warstwy obrony.

Grunt to znaleźć złoty środek – taki, w którym użytkownik wciąż chce wypełnić formularz, a bot – niczym Balrog we Władcy Pierścieni – po prostu nie przejdzie.

O autorze.

Od lat związany z szeroko rozumianą informatyką. Pierwszą stronę stworzyłem w liceum, za co otrzymałem wyróżnienie.

Ciągle uczę się, aby dorównać tempu rozwoju nowoczesnych technologii łącząc je z wiedzą o psychologii aby zwiększać skuteczność stron i aplikacji internetowych.