reCAPTCHA dla PrestaShop: ochrona sklepu przed spamem i botami

Ostatnia aktualizacja: czerwiec 2026.

Sklep PrestaShop działający bez CAPTCHA to nie hipotetyczne ryzyko — to cel, który zautomatyzowany ruch znajduje sam. Boty skanują internet w poszukiwaniu standardowych endpointów formularzy PrestaShop, a gdy znajdą Twój sklep, zaczynają je zasypywać: fałszywe rejestracje w AuthController, śmieci w formularzu kontaktowym, próby zgadywania kombinacji haseł przy logowaniu, masowe wysyłki e-maili do resetowania hasła. Do żadnego z tych działań nie trzeba wiedzieć, że Twój sklep w ogóle istnieje. Formularze są częścią PrestaShop, boty je znają, a standardowa instalacja PrestaShop ma zerową ochronę przed botami na każdym z nich.

Ten przewodnik pokazuje, jak zamknąć tę lukę: co boty faktycznie robią w sklepie PrestaShop, które konkretnie formularze atakują i jak CAPTCHA zatrzymuje każdy z tych ataków. Jeśli martwisz się drugą stroną medalu — dodaniem ochrony bez odstraszania prawdziwych klientów irytującymi wyzwaniami — to kwestia konwersji, którą omawiamy osobno w artykule reCAPTCHA bez irytowania prawdziwych klientów. Tutaj skupiamy się na zagrożeniu i obronie.

Co boty faktycznie robią w sklepie PrestaShop

„Spam i boty” brzmią ogólnie, dopóki nie zobaczysz ich we własnym panelu administracyjnym. Tak wygląda to w realnej instalacji PrestaShop, z podziałem na części sklepu, które ponoszą szkody.

Wspólny mianownik jest prosty: szkoda rzadko wygląda jak spektakularne włamanie. To powolna degradacja — baza klientów, której nie możesz już ufać, skrzynka wsparcia, której boisz się otwierać, i reputacja e-mailowa po cichu spadająca w dół. CAPTCHA na właściwych formularzach odcina większość tego ruchu już przy wejściu. (Przy poważniejszych scenariuszach — masowym testowaniu wykradzionych danych logowania, nadużyciach przy zamówieniach i kartach oraz skimmerach — CAPTCHA jest jedną z kilku warstw; zobacz pełną checklistę wzmacniania bezpieczeństwa oraz anatomię ataku w stylu Magecart.)

Które formularze PrestaShop chronić, a które zostawić w spokoju

Odruch „dodajmy CAPTCHA wszędzie” jest błędny. Boty koncentrują się na kilku endpointach, a każdy chroniony formularz dodaje odrobinę tarcia. Chroń te miejsca, w które trafiają ataki, nie te, które podpowiada intuicja.

Chroń w pierwszej kolejności — tutaj są boty

• Formularz rejestracji. Najważniejszy cel botów w każdym sklepie PrestaShop. Bez ochrony to właśnie tutaj rośnie sterta fałszywych kont. Punkt obowiązkowy.
• Formularz kontaktowy. Drugi najczęściej atakowany. To bariera między Tobą a skrzynką obsługi klienta pełną szumu.
• Formularz logowania. Zatrzymuje próby brute-force, zanim staną się jednocześnie problemem obciążenia serwera i przejętych kont.

Chroń w następnej kolejności

• Resetowanie hasła. Zamyka wektor zalewu e-mailami resetującymi, który obniża reputację nadawcy.
• Zapis do newslettera. Trzyma fałszywe subskrypcje poza Twoją listą.
• Recenzje produktów (jeśli korzystasz z modułu recenzji). Boty publikują fałszywe recenzje, aby manipulować ocenami.

Zostaw w spokoju, chyba że masz potwierdzony problem

• Realizacja zamówienia. Dodanie widocznej CAPTCHA na etapie realizacji zamówienia to strzał we własną stopę — zwiększa porzucenia na najcenniejszej stronie sklepu. Ruszaj ją tylko wtedy, gdy widzisz realne oszustwa przy składaniu zamówień, i wyłącznie z niewidoczną punktacją (nigdy z checkboxem). Te kompromisy to dokładnie problem „nie irytuj prawdziwych klientów” omówiony w przewodniku uzupełniającym.
• Wyszukiwarka i dodawanie do koszyka. Rzadko są rzeczywistym celem; tarcie nie jest tego warte.

reCAPTCHA v2, v3 czy hCaptcha — którą ochronę wdrożyć

Wybrana wersja decyduje zarówno o tym, jak trudno botowi przejść dalej, jak i o tym, jak bardzo zauważy ją prawdziwy klient. Sklep PrestaShop ma trzy realistyczne opcje:

W większości sklepów PrestaShop wybór sprowadza się do v3 z niewidoczną punktacją albo v2 lub hCaptcha z jawnym wyzwaniem. Aktualny moduł mprrecaptcha pozwala wybrać reCAPTCHA v2, reCAPTCHA v3 albo hCaptcha oraz ustawić próg punktacji v3; nie przełącza jednak automatycznie z v3 na v2 przy granicznych wynikach, więc obsługa niskich wyników jest decyzją o dostrojeniu i odrzuceniu, a nie drugim wyzwaniem. Jaki dokładnie próg ustawić i jak uniknąć blokowania prawdziwych ludzi, to część pracy związana z dostrojeniem — omówiona w przewodniku uzupełniającym.

Dodanie CAPTCHA do formularzy PrestaShop — mechanika

PrestaShop nie zawiera CAPTCHA, więc ochrona oznacza moduł. Kluczowe jest jak moduł się podpina, bo od tego zależy, czy faktycznie blokuje wysłanie formularza, czy tylko ozdabia stronę.

Krok 1 — wygeneruj klucze

Dla reCAPTCHA zarejestruj stronę pod adresem www.google.com/recaptcha/admin; dla hCaptcha — w panelu hCaptcha. W obu przypadkach otrzymasz publiczny Site Key (renderowany na stronie) i prywatny Secret Key (używany po stronie serwera do weryfikacji). Dodaj zarówno domenę z www, jak i bez www. Klucze są przypisane do domeny — niedopasowana domena może zepsuć walidację CAPTCHA albo zablokować prawidłowe zgłoszenia, dlatego zarejestruj osobną parę dla każdego środowiska i przetestuj, czy formularz zamyka się bezpiecznie (odrzuca zgłoszenie zamiast po cichu je przepuszczać), gdy token nie przejdzie weryfikacji.

Krok 2 — jak podpina się poprawny moduł

Najważniejsze ustawienia to dostawca, klucze, chronione formularze i próg v3.

W prawdziwym module hooki wyświetlania renderują widżet, a hooki akcji odrzucają zgłoszenie, zanim PrestaShop utworzy konto, wiadomość lub subskrypcję. To odpowiednie hooki ze źródeł mprrecaptcha.

public function getHooks()
{
    return [
        'displayHeader',
        'displayFooter',
        'displayCustomerLoginFormAfter',
        'displayCustomerAccountForm',
        'displayNewsletterRegistration',
        'displayGDPRConsent',
        'actionContactFormSubmitBefore',
        'actionSubmitAccountBefore',
        'actionCustomerLoginBefore',
        'actionNewsletterRegistrationBefore',
    ];
}

To właśnie odróżnia realną ochronę od pozoru. Bot nie wypełnia formularza ręcznie; wysyła żądanie POST prosto do kontrolera. Dlatego weryfikacja musi odbywać się po stronie serwera, zanim PrestaShop przetworzy zgłoszenie — a nie tylko jako widżet narysowany na stronie. Kluczowy wymóg jest taki sam w każdej wersji: token jest sprawdzany po stronie serwera przed przetworzeniem konta, wiadomości kontaktowej, logowania albo zapisu do newslettera. Dokładne nazwy hooków różnią się między gałęziami — starsze wydania 1.6/1.7 mają inne przepływy front-controllerów i formularzy niż 8/9, więc dobrze zbudowany moduł podpina się pod te zweryfikowane hooki Before, które istnieją w docelowej wersji (na przykład hooki zgłoszenia rejestracji, formularza kontaktowego, logowania i newslettera). Niezależnie od użytego hooka moduł weryfikuje token przez endpoint siteverify Google albo hCaptcha i odrzuca żądanie, zanim konto lub wiadomość zostaną utworzone. Warstwa wyświetlania korzysta z displayCustomerAccountForm, displayCustomerLoginFormAfter oraz displayHeader/displayFooter, aby wstrzyknąć widżet i załadować skrypt. Jeśli moduł tylko renderuje oznaczenie, ale nie zabezpiecza hooków Before, bot wysyłający POST bezpośrednio przechodzi obok niego.

Krok 3 — sprawdź, czy naprawdę blokuje

Nie zakładaj — testuj. Wyślij każdy chroniony formularz jako zwykły klient, aby potwierdzić, że prawidłowe użycie nadal działa, a potem sprawdź panel dostawcy, czy weryfikacje są rejestrowane. Najczęstsza awaria konfiguracji to formularz, który wygląda na chroniony, ale którego hook Before nie jest podpięty, więc boty przechodzą dalej, podczas gdy Ty sądzisz, że masz ochronę.

Wybór modułu specyficznego dla PrestaShop

Ponieważ ochrona działa albo nie działa właśnie na tych hookach po stronie serwera, wybór modułu ma większe znaczenie niż marka CAPTCHA. Nasz moduł mprrecaptcha (PrestaShop od 1.6 do 9) powstał dokładnie do tego: obsługuje reCAPTCHA v2, v3 i hCaptcha, a w każdej wspieranej gałęzi podpina się pod rzeczywiste hooki wysyłki po stronie serwera dla rejestracji, kontaktu, logowania i newslettera — dzięki temu bezpośredni POST bota jest weryfikowany i odrzucany w kontrolerze, a nie tylko ukrywany przed stroną. Co to oznacza dla Ciebie? Wybierasz w panelu administracyjnym, które formularze chronić, zostawiasz realizację zamówienia bez tarcia, a fałszywe rejestracje i spam kontaktowy przestają napływać — bez edytowania plików motywu i bez dotykania rdzenia PrestaShop, więc ochrona przetrwa aktualizacje. Moduł udostępnia też hook displayGDPRConsent, aby skrypt CAPTCHA można było powiązać z przepływem zgód, co w UE ma znaczenie (poniżej).

Pułapka RODO, której nie możesz pominąć

Google reCAPTCHA ładuje JavaScript Google i wysyła adres IP oraz dane o zachowaniu odwiedzającego na serwery Google — co w świetle RODO jest przetwarzaniem wymagającym podstawy prawnej, a kilka europejskich organów ochrony danych (w tym francuski CNIL) zwracało na to uwagę. To tworzy realne napięcie dla sklepu z UE: zablokujesz reCAPTCHA do czasu zgody na cookies, a formularze pozostaną bez ochrony dla odwiedzających, którzy nie wyrażą zgody; załadujesz ją mimo wszystko, a pojawi się ryzyko regulacyjne. Nie ma jednej, powszechnie „poprawnej” odpowiedzi — to decyzja o ryzyku. Dwie praktyczne ścieżki: powiązać CAPTCHA z mechanizmem zgód (właśnie do tego istnieje wspomniany hook displayGDPRConsent) albo całkowicie ominąć transfer danych do Google, używając hCaptcha, która nie udostępnia danych Google. To tylko jeden fragment szerszego obrazu zgodności; perspektywę właściciela sklepu znajdziesz w prostym przewodniku po bezpieczeństwie.

CAPTCHA to jedna warstwa, nie cały mur

CAPTCHA zatrzymuje zautomatyzowane nadużycia formularzy — fałszywe konta, spam kontaktowy, zalew resetów, szum brute-force. Nie zatrzymuje wszystkiego, a traktowanie jej jako całej obrony jest błędem. Rozproszone boty rotujące adresy IP, zalewy ruchu i osoby, które już przeszły przez formularz, wymagają innych warstw:

• Blokowanie złych botów i adresów IP dla ruchu, który w ogóle nie powinien docierać do Twoich formularzy — zobacz blokowanie złych botów i niechcianego ruchu oraz blokady IP dla problematycznych odwiedzających.
• Ochrona panelu administracyjnego — CAPTCHA pomaga przy logowaniu w sklepie, ale panel administracyjny potrzebuje uwierzytelniania dwuskładnikowego i polityki haseł: 2FA i bezpieczeństwo administracji.
• Obciążenie generowane przez roboty indeksujące, którego żadna CAPTCHA nie rozwiąże, na przykład zalew zapytań z wyszukiwania fasetowego: jak przetrwać zalew ?q=.
• Jeśli coś jednak się przedostanie — plan reagowania na incydent w artykule reakcja na naruszenie danych.

Uczciwy wniosek: dodaj CAPTCHA do formularzy rejestracji, kontaktu i logowania za pomocą modułu, który zabezpiecza hooki Before po stronie serwera, zostaw realizację zamówienia w spokoju, świadomie rozstrzygnij kwestię RODO i traktuj efekt jako jedną solidną warstwę wzmocnionego sklepu — nie jako metę. Zrobione w ten sposób, powolne gnicie fałszywych kont i zakopanych wiadomości do obsługi po prostu się kończy, a Ty odzyskujesz dane klientów i własną skrzynkę.

Najczęściej zadawane pytania

Na których formularzach naprawdę warto dodać CAPTCHA?

Chroń te miejsca, w których są boty, a nie wszystko. Trzy formularze do zabezpieczenia w pierwszej kolejności to rejestracja (cel numer jeden — tutaj rośnie sterta fałszywych kont), kontakt (utrzymuje skrzynkę obsługi klienta w używalnym stanie) oraz logowanie (zatrzymuje szum brute-force). Kolejny poziom: resetowanie hasła, zapis do newslettera i recenzje produktów, jeśli korzystasz z modułu recenzji. Zostaw realizację zamówienia w spokoju, chyba że masz potwierdzone oszustwa — widoczna CAPTCHA w tym miejscu zwiększa porzucenia na najcenniejszej stronie, a jeśli naprawdę musisz ją dodać, użyj tylko niewidocznej punktacji, nigdy checkboxa.

reCAPTCHA v2, v3 czy hCaptcha — co wybrać?

v3 jest niewidoczna i ocenia zachowanie w skali 0.0–1.0 według ustawionego przez Ciebie progu, co pasuje do formularzy o dużym ruchu albo wrażliwych na konwersję, ale wymaga ostrożnego dostrojenia, aby nie odrzucać prawdziwych ludzi z niskimi wynikami. v2 i hCaptcha pokazują jawne wyzwanie, co jest w porządku na formularzach kontaktowych i rejestracyjnych, gdzie dodatkowe kliknięcie jest akceptowalne. Wyróżnikiem hCaptcha dla sklepów z UE jest to, że nie wysyła danych do Google. Moduł mprrecaptcha obsługuje wszystkie trzy opcje i pozwala ustawić próg punktacji v3; nie wykonuje automatycznego przełączenia z v3 do v2 przy granicznych wynikach, więc obsługa niskiego wyniku jest decyzją o dostrojeniu i odrzuceniu.

Mój formularz wygląda na chroniony, ale spam nadal przechodzi — co jest nie tak?

Prawie zawsze weryfikacja jest dekoracją, a nie egzekwowaną blokadą. Bot nie wypełnia formularza ręcznie — wysyła POST prosto do kontrolera — więc jeśli moduł tylko renderuje widżet na stronie, ale nie zabezpiecza hooków Before po stronie serwera (hooków wysyłki rejestracji, kontaktu, logowania i newslettera), bezpośredni POST przechodzi obok niego. Realna ochrona weryfikuje token przez endpoint siteverify dostawcy przed utworzeniem konta, wiadomości lub subskrypcji. Przetestuj to: wyślij każdy formularz jako zwykły klient, aby potwierdzić, że nadal działa, a potem sprawdź panel dostawcy, czy weryfikacje są rejestrowane.

Dlaczego CAPTCHA „przestaje działać” po zmianie domeny albo dodaniu www?

Klucze reCAPTCHA i hCaptcha są przypisane do domeny. Jeśli Twój Site Key i Secret Key zostały zarejestrowane dla jednego hosta, nie zweryfikują się na innym — dlatego niedopasowany albo brakujący wpis www / bez www może zepsuć walidację albo blokować prawidłowe zgłoszenia. Dodaj do klucza domenę z www i bez www oraz zarejestruj osobną parę kluczy dla każdego środowiska (staging i produkcja). Upewnij się też, że formularz zamyka się bezpiecznie — odrzuca zgłoszenia, gdy token nie przejdzie weryfikacji, zamiast po cichu je przepuszczać.

Czy używanie Google reCAPTCHA jest problemem RODO dla sklepu z UE?

To realna decyzja o ryzyku, a nie rozstrzygnięte tak/nie. reCAPTCHA ładuje JavaScript Google i wysyła do Google adres IP oraz zachowanie odwiedzającego, co jest przetwarzaniem wymagającym podstawy prawnej w RODO, a kilka organów z UE (w tym francuski CNIL) zwracało na to uwagę. Dwie praktyczne ścieżki: powiązać CAPTCHA z mechanizmem zgód (hook displayGDPRConsent istnieje właśnie do tego) albo całkowicie ominąć transfer danych do Google, używając hCaptcha. Niezależnie od wyboru, nigdy nie uruchamiaj skryptu CAPTCHA przed zgodą, jeśli traktujesz go jako niekonieczny.

Czy CAPTCHA zastępuje inne zabezpieczenia?

Nie — to jedna warstwa. CAPTCHA zatrzymuje zautomatyzowane nadużycia formularzy: fałszywe konta, spam kontaktowy, zalew e-maili resetujących, szum brute-force. Nie zatrzyma rozproszonych botów rotujących adresy IP, zalewów ruchu ani nikogo, kto już przeszedł przez formularz. Połącz ją z blokowaniem złych botów i adresów IP dla ruchu, który w ogóle nie powinien docierać do formularzy, uwierzytelnianiem dwuskładnikowym i polityką haseł w panelu administracyjnym oraz planem reagowania, jeśli coś jednak się przedostanie. CAPTCHA na rejestracji, kontakcie i logowaniu to solidna warstwa wzmocnionego sklepu, nie meta.