Złośliwy bot często nie wygląda jak atak na bazę. To czyste wejścia na logowanie, koszyk albo listę produktów, powtarzane z wielu adresów. W logu sklepu widać skok błędów. Na serwerze widać zajęte procesy PHP.
Cloudflare stoi przed sklepem: DNS domeny wskazuje na krawędź, szyfrowanie kończy się tam, a serwer sklepu nie musi być publiczny. Ocena bota, wyzwanie JavaScript i limit zapytań tną ruch, zanim dojdzie do PHP i bazy.
Po co to sklepowi
Stosujesz to, gdy sklep albo API dostaje masę żądań, które nie kupują: próby haseł, zbieranie katalogu, testowanie kart. Zweryfikowane boty, wyszukiwarka i monitoring, zostają wpuszczone. Reszta z niską oceną dostaje wyzwanie albo blokadę.
Limit zapytań ustawiasz na logowanie, wyszukiwarkę i koszyk. Webhook płatności musi być wyjątkiem. Inaczej ginie zamówienie.
Jak to ustawić
W Cloudflare na domenie sklepu: pełne szyfrowanie do originu, certyfikat origin, poziom zabezpieczeń średni. W Bots włączasz Bot Fight. W planie Pro i wyżej Super Bot Fight: pewna automatyzacja zablokowana, prawdopodobna z wyzwaniem, zweryfikowane boty wpuszczone.
W WAF dodajesz regułę na ścieżki logowania z niską oceną bota. Osobny limit: kilkanaście żądań na minutę na IP na logowanie. Wyjątek dla ścieżki Stripe, PayU albo Przelewy24.
Jeśli wyzwanie łapie prawdziwych klientów za firmowym proxy, zwężasz regułę do ścieżki, nie do całej domeny. Na serwerze sklepu port 443 otwierasz tylko od adresów Cloudflare.
Szerszy opis warstwy: security.
W skrócie: krawędź zdejmuje z serwera ruch, który nie kupuje. Reguła bez wyjątku dla płatności psuje checkout. Log z Cloudflare mówi, czy tniecie boty, czy klientów.