Ochrona formularzy przed spamem bez CAPTCHA: walidacja po stronie serwera i filtr antyspamowy

Spam w formularzach kontaktowych i ryzyko dla CRM oraz poczty

Po skutecznej optymalizacji SEO i wzroście ruchu organicznego serwis zaczął stabilnie pozyskiwać ponad 600 użytkowników miesięcznie. Razem z ruchem wzrosła liczba zapytań — dokładnie tego oczekiwał biznes.

Równolegle pojawił się jednak problem, który często idzie w parze z widocznością w Google: spam w formularzach. Boty zaczęły masowo „testować” publicznie dostępne pola, wysyłając zgłoszenia:

• z przypadkowymi imionami i nazwiskami,
• z nieistniejącymi adresami e-mail,
• z bardzo krótkimi / losowymi numerami telefonu,
• z szablonowymi treściami bez związku z ofertą.

Z czasem przestało to być tylko „irytujące” — pojawiły się realne ryzyka biznesowe:

• zaśmiecanie CRM i spadek jakości danych,
• strata czasu zespołu na obsługę fałszywych leadów,
• zaburzenie analityki (fałszywa konwersja, złe wnioski),
• ryzyko reputacyjne poczty: automatyczne odpowiedzi i powiadomienia wysyłane
• na nieprawdziwe adresy zwiększają szanse na problemy ze spamem.

Kluczowe było to, że część spamu nie przechodziła przez „interfejs” strony, tylko trafiała bezpośrednio na endpoint API. Czyli sama walidacja w formularzu nie wystarczała.

CAPTCHA była rozważana, ale jako ostateczność: potrafi obniżyć konwersję i psuje doświadczenie użytkownika, a w projektach międzynarodowych jest szczególnie uciążliwa. Dlatego celem było rozwiązanie „niewidzialne”, ale skuteczne.

Ochrona formularza przed spamem bez CAPTCHA i bez spadku konwersji

Głównym celem było wdrożenie ochrony formularzy przed spamem bez CAPTCHA, tak aby realny użytkownik nie zauważył żadnej „walki z botami”, a biznes od razu odczuł poprawę jakości leadów.

Od strony biznesowej cele były konkretne:

• zatrzymać spam wysyłany bezpośrednio na API,
• chronić CRM i skrzynki mailowe przed śmieciowymi zgłoszeniami,
• odciążyć zespół i wyeliminować ręczne filtrowanie,
• ograniczyć ryzyko problemów z dostarczalnością e-maili (reputacja domeny),
• utrzymać (a najlepiej poprawić) konwersję formularzy.

Od strony UX i produktu:

• formularze mają pozostać szybkie i proste,
• żadnych dodatkowych kroków typu CAPTCHA, quizy czy podejrzane checkboksy,
• poprawne działanie autouzupełniania w przeglądarkach i na telefonach,
• spójne działanie dla użytkowników z różnych krajów.

Od strony technicznej:

• rozwiązanie niezależne od płatnych usług,
• skalowalne razem z ruchem,
• wielowarstwowe (nie jeden „magiczny” warunek),
• oparte o kontekst żądania (źródło, nagłówki, zachowanie),
• do ponownego użycia we wszystkich formularzach.

W praktyce oznaczało to jedno: walidacja po stronie serwera miała być „bramką”, której bot nie obejdzie prostym POST-em. Weryfikacja Origin/Referer jako warstwa ochrony jest często wskazywana jako element wzmacniający bezpieczeństwo.

Mniej spamu w CRM i czystsze leady bez pogorszenia UX

Efekty były zauważalne krótko po wdrożeniu i potwierdzone w kolejnych tygodniach stabilnej pracy.

Najważniejsze rezultaty biznesowe:

• spam został ograniczony praktycznie do zera (w praktyce ~98% mniej),
• do CRM i na e-mail trafiają głównie realne zapytania,
• zespół przestał marnować czas na „śmieciowe” zgłoszenia,
• niższe ryzyko problemów po stronie poczty (mniej wysyłek na nieistniejące adresy).

Z perspektywy użytkownika:

• brak CAPTCHA i dodatkowych barier,
• brak spadku konwersji,
• poprawne działanie autouzupełniania i wysyłki formularza.

Z perspektywy utrzymania:

• jedno podejście dla wielu formularzy,
• logika po stronie serwera trudna do obejścia,
• brak kosztów licencji / abonamentów.

1. Analiza źródeł spamu i wzorców ataku

Na starcie przeanalizowałem zgłoszenia oraz wzorce wysyłki. To pozwoliło potwierdzić, że spam przychodzi:

• bez realnego kontekstu strony,
• z nietypowymi nagłówkami,
• z nienaturalnym czasem „wypełnienia”,
• często seriami (z jednego źródła/IP lub powtarzalnych danych).

2. Wielowarstwowy filtr antyspamowy bez CAPTCHA

Zamiast jednego mechanizmu wdrożyłem zestaw niezależnych kontroli, które razem budują skuteczną barierę:

• honeypot (ukryte pole) — niewidoczne dla człowieka, często wypełniane przez boty, więc łatwo odfiltrowuje automaty.
• kontrola czasu wysyłki — zbyt szybkie wysłanie wygląda jak automat,
  weryfikacja Origin/Referer — żądanie ma wyglądać jak wysłane z realnej strony, nie „z powietrza”.
• walidacja adresu strony (currentPage) — dodatkowa kontrola kontekstu,
  ograniczanie liczby zgłoszeń (rate limiting) po IP i po e-mailu,
• walidacja danych (e-mail/telefon/imię) + proste heurystyki na „tokeny” i losowe stringi.

3. Ujednolicenie logiki dla wielu formularzy

Ta sama polityka ochrony działa dla:

• formularza standardowego,
• formularza pełnego,
• formularza minimalnego,
• formularza partnerskiego.

To upraszcza utrzymanie: jedna logika po stronie serwera, spójne zasady i jedno miejsce do rozwoju.