Bezpieczeństwo panelu i sklepu w Hummerce to zestaw mechanizmów, które chronią panel administracyjny, konta klientów i dane sklepu przed przejęciem, wyciekiem i nadużyciem. Mechanizmy są częścią platformy - włącza się i konfiguruje je per sklep, zamiast budować zabezpieczenia od podstaw dla każdego wdrożenia z osobna.
Stan na wersję Hummerce 2.35 (ostatnie zmiany w mechanizmach bezpieczeństwa: 2.35.63), aktualizacja 2026-10-07.
- 2FA zatrzymuje najczęstszy scenariusz przejęcia sklepu - przejęte lub wyciekłe hasło administratora nie wystarcza do wejścia do panelu.
- Mniej ryzyka nieuprawnionych zamówień i zmian danych - wykradziona sesja klienta lub administratora przestaje działać.
- Mniejsze ryzyko naruszenia RODO - adresy e-mail i identyfikatory sesji nie wyciekają do statystyk, logów i linków.
- Lepsze wyniki w audytach i skanerach bezpieczeństwa zlecanych przez partnerów (np. banki, operatorzy płatności, klienci korporacyjni).
- Szybkie uruchomienie - mechanizmy są częścią platformy, więc włączenie to zwykle kilka godzin, nie projekt budowany od zera.
- Kontrola dostępu zespołu - historia zmian i uprawnienia pozwalają ustalić, kto i kiedy zmienił dane, i ograniczyć dostęp pracowników, agencji i podwykonawców do niezbędnego zakresu.
Platforma jest regularnie wzmacniana na podstawie niezależnego audytu bezpieczeństwa (testy penetracyjne) i obserwacji zautomatyzowanych prób ataków na sklepy - jeden zestaw zabezpieczeń dla wszystkich sklepów Hummerce, zamiast rozwiązań indywidualnych. Które mechanizmy są aktywne w Waszym sklepie, zależy od jego konfiguracji i szablonu - na zlecenie sprawdzimy to i uruchomimy brakujące (zobacz Wdrożenie).
| Mechanizm |
Chroni |
| Dwuetapowe logowanie (2FA) |
panel |
| Uprawnienia administratorów |
panel |
| Ochrona sesji |
panel, konta klientów |
| Ochrona formularzy (CSRF) |
panel, sklep |
| Nagłówki bezpieczeństwa |
sklep |
| Dane osobowe poza adresami stron |
klienci |
| Walidacja danych wejściowych |
panel, sklep |
| Siła haseł klientów |
konta klientów |
| reCAPTCHA |
formularze sklepu |
| Historia zmian |
panel |
| Ochrona sklepu testowego |
środowisko testowe |
| Szyfrowane połączenie (HTTPS) |
panel, sklep |
- Po podaniu loginu i hasła administrator potwierdza logowanie drugim składnikiem - bez niego samo hasło nie wystarcza do wejścia do panelu.
- Dwie metody do wyboru, jedna aktywna na koncie w danym momencie:
- kod z e-maila - jednorazowy kod wysyłany na adres konta, ważny przez ograniczony czas; wysłanie nowego kodu unieważnia poprzedni,
- aplikacja uwierzytelniająca (np. Google Authenticator, Microsoft Authenticator) - kod z aplikacji, konfigurowany przez zeskanowanie kodu QR.
- Działa na dwóch poziomach: globalny włącznik na poziomie sklepu i indywidualne włączenie oraz wybór metody na własnym koncie każdego administratora.
- Zaufana przeglądarka - przy weryfikacji można zapamiętać przeglądarkę na ustaloną w konfiguracji liczbę dni. Zapamiętanie można powiązać z wersją przeglądarki, a administrator może w każdej chwili cofnąć wszystkie zaufane przeglądarki swojego konta.
- Blokada po błędnych kodach - po serii błędnych prób konto jest czasowo blokowane. Blokadę może wcześniej zdjąć inny administrator.
- Weryfikacja sesji - sklep zapamiętuje cechy przeglądarki i połączenia, z których zalogowano się do konta. Gdy w trakcie sesji zmienią się w sposób wskazujący na przejęcie, sesja jest unieważniana, a użytkownik musi zalogować się ponownie. Osobne włączniki dla klientów sklepu i dla administratorów panelu.
- Nowy identyfikator sesji po zalogowaniu i wylogowaniu - identyfikator nadany przed zalogowaniem nie działa po zalogowaniu.
- Identyfikator sesji tylko w ciasteczku - nie pojawia się w adresach stron, więc nie trafia do linków udostępnianych dalej, statystyk (np. Google Analytics), logów serwerów ani wyników wyszukiwania.
- Czas bezczynności - sesja w sklepie i w panelu wygasa po okresie bezczynności. Inną wartość ustawia się w ramach prac wdrożeniowych.
- Chroni przed sytuacją, w której obca strona internetowa próbuje w imieniu zalogowanego klienta lub administratora wysłać formularz do sklepu (np. zmienić dane, złożyć zamówienie, wykonać operację w panelu).
- Sklep przyjmuje operacje zmieniające dane tylko wtedy, gdy pochodzą z jego własnych stron. Pozostałe są odrzucane.
- Obejmuje formularze sklepu i operacje w panelu. Osobne włączniki dla sklepu i dla panelu.
- Zewnętrzne usługi, które wysyłają dane do sklepu (np. powiadomienia z bramek płatności, integracje), są uwzględniane w konfiguracji ochrony. REST API ma własne uwierzytelnianie.
- Sklep dodaje do stron standardowe instrukcje dla przeglądarki, które ograniczają nadużycia po stronie klienta: wymuszenie połączenia szyfrowanego (HTTPS) przy kolejnych wizytach, zakaz osadzania stron sklepu w ramkach na obcych witrynach, zakaz "zgadywania" typu plików przez przeglądarkę, ograniczenie informacji przekazywanych innym stronom w adresie odsyłającym, zablokowanie dostępu stron sklepu do kamery, mikrofonu i lokalizacji oraz polityka źródeł treści (Content Security Policy).
- Wartości są dobrane tak, żeby nie blokować Google Tag Managera ani typowych integracji. Politykę dopasowaną do skryptów konkretnego sklepu ustawia się przy wdrożeniu.
- Moduł włącza się i wyłącza w panelu, bez zmian w konfiguracji serwera.
- Linki generowane przez sklep (m.in. potwierdzenie konta, zapis i rezygnacja z newslettera, przypomnienie hasła) zawierają zamiast adresu e-mail identyfikator. Linki działają jak wcześniej.
- Adres e-mail nie jest widoczny w pasku adresu przeglądarki ani w narzędziach analitycznych.
Dane przekazywane do sklepu są sprawdzane przed użyciem. Poprawki wynikające z audytu bezpieczeństwa trafiają do kolejnych wydań i działają po aktualizacji, bez konfiguracji - dlatego zalecamy utrzymywanie sklepu na najnowszej wersji.
Minimalny poziom hasła przy rejestracji (niski, średni, wysoki albo własna reguła) i graficzny wskaźnik siły hasła w formularzu. Zalecamy ustawienie co najmniej poziomu średniego.
Google reCAPTCHA v3 ocenia zachowanie użytkownika w tle; test "nie jestem robotem" pojawia się tylko przy podejrzanym wyniku. Włączana per formularz.
Role z dostępem do wybranych pozycji menu i widoków - administrator widzi tylko to, do czego ma prawo. Asystent AI (MCP) korzysta z tych samych uprawnień co konto w panelu. Szczegóły: Uprawnienia administratorów.
Zapis zmian w sklepie - logowania administratorów, zmiany zamówień, towarów, klientów, konfiguracji i innych obiektów - z możliwością filtrowania i archiwizacji. Szczegóły: Historia zmian.
Sklep na środowisku testowym jest dostępny tylko dla osób z linkiem dostępowym. Pozostałe wejścia (w tym roboty wyszukiwarek) są przekierowywane na wskazany adres, np. sklep produkcyjny - testowa wersja nie trafia do Google ani do klientów. Link dostępowy przekazujemy zespołowi sklepu przy wdrożeniu. Zgłaszanie błędów bezpośrednio ze sklepu opisuje strona Tryb serwisowy.
- Pełny pakiet opisany na tej stronie - od wersji 2.35. Starsze wersje mają tylko część mechanizmów - zalecamy aktualizację do najnowszego wydania.
- Ostatnie zmiany w mechanizmach bezpieczeństwa: wersja 2.35.63.
- Wersja sklepu 2.35 dla pełnego pakietu (zobacz Wersja).
- Szablon sklepu Bootstrap 5 lub Bootstrap 4 - ochrona formularzy (CSRF) i identyfikator sesji tylko w ciasteczku są w nich przygotowane. Starsze i indywidualne szablony wymagają dostosowania.
- Certyfikat SSL i działanie sklepu wyłącznie przez HTTPS - warunek wymuszania połączenia szyfrowanego.
- 2FA przez e-mail - adres e-mail na koncie administratora i działająca wysyłka poczty ze sklepu.
- 2FA przez aplikację - telefon z aplikacją uwierzytelniającą.
- reCAPTCHA - klucze z konta Google sklepu.
- Rekord SPF domeny pocztowej po stronie sklepu (DNS) - utrudnia podszywanie się pod adres sklepu w e-mailach.
- Działa po aktualizacji - walidacja danych, identyfikator zamiast adresu e-mail w linkach, uprawnienia i historia.
- Wymaga uruchomienia i konfiguracji per sklep - 2FA, ochrona sesji, ochrona formularzy (CSRF), nagłówki bezpieczeństwa, siła haseł i reCAPTCHA. Zakres:
- przegląd, które mechanizmy są aktywne w sklepie,
- uruchomienie modułu 2FA, ustawienie parametrów, test logowania kodem z e-maila i aplikacją, przekazanie administratorom informacji o konfiguracji kont,
- włączenie weryfikacji sesji i sprawdzenie na ruchu sklepu,
- uruchomienie nagłówków bezpieczeństwa i sprawdzenie sklepu (analityka, płatności, czaty, widgety, osadzone treści),
- przygotowanie ochrony formularzy CSRF: obserwacja przez kilka dni, uwzględnienie zewnętrznych usług, włączenie, testy logowania, koszyka, zamówienia i płatności,
- ustawienie siły haseł i ewentualnie reCAPTCHA na wybranych formularzach,
- testy na środowisku testowym i uruchomienie produkcyjne.
- Minimalny szacowany czas:
- 2FA - od 1 h,
- weryfikacja sesji - od 0,5 h,
- nagłówki bezpieczeństwa - od 2 h,
- ochrona formularzy CSRF - szablon Bootstrap 5 - od 3 h, szablon Bootstrap 4 - od 4 h,
- siła haseł - od 1 h,
- reCAPTCHA - od 1 h,
- cały pakiet - szablon Bootstrap 5 - od 8 h, szablon Bootstrap 4 - od 10 h.
- Czas konkretnego wdrożenia zależy od jego zakresu - wyceniamy go indywidualnie.
- Od czego zależy czas:
- szablon sklepu - indywidualne szablony wymagają dostosowania formularzy i skryptów,
- liczba zewnętrznych usług wysyłających dane do sklepu (bramki płatności, kurierzy, ERP, marketplace'y),
- skrypty i widgety firm zewnętrznych na stronach sklepu - mogą wymagać dopasowania nagłówków,
- wersja sklepu - sklep starszy niż 2.35 wymaga najpierw aktualizacji (wycena osobno),
- polityka źródeł treści dopasowana do skryptów sklepu - wycena osobno.
- 2FA dotyczy panelu administracyjnego - klienci sklepu logują się hasłem (lub przez Google, jeśli moduł jest włączony).
- Ustawienia 2FA (metodę, zaufane przeglądarki) administrator zmienia na własnym koncie. Po włączeniu 2FA w sklepie sprawdźcie, czy każdy administrator skonfigurował je na swoim koncie.
- 2FA nie ma kodów zapasowych - zalecamy, żeby co najmniej dwóch administratorów miało aktywne 2FA, a aplikacja uwierzytelniająca była skonfigurowana na telefonie służbowym.
- 2FA nie obejmuje dostępu przez klucz REST API i MCP - klucze trzeba chronić jak hasła i usuwać po zakończeniu współpracy.
- Wyczyszczenie ciasteczek przeglądarki (lub - przy powiązaniu z wersją przeglądarki - jej aktualizacja) wymaga ponownego podania kodu.
- Weryfikacja sesji może wylogowywać użytkowników, którym w trakcie wizyty zmienia się sieć (np. telefon przełączający się między Wi-Fi a siecią komórkową, niektóre sieci firmowe i VPN). Przed włączeniem warto to przetestować na ruchu sklepu.
- Ochrona formularzy CSRF włączona bez przygotowania może zablokować powiadomienia z bramek płatności i integracji - dlatego wymaga wdrożenia, a nie tylko włączenia.
- Nagłówki bezpieczeństwa podnoszą poziom ochrony, ale nie zastępują polityki dopasowanej do skryptów danego sklepu.
- Zakaz osadzania w ramkach na obcych witrynach blokuje też celowe osadzanie sklepu na innych stronach (np. konfigurator na stronie partnera) - taki przypadek wymaga zmiany ustawień.
- Wymuszenie HTTPS przez przeglądarkę działa tylko w sklepie z certyfikatem SSL.
- Mechanizmy nie zastępują polityki bezpieczeństwa sklepu - silnych i unikalnych haseł administratorów, usuwania kont byłych pracowników (od wersji 2.35.63 pomaga w tym automatyczne zamykanie logowania nieaktywnym kontom i przycisk Wyłącz logowanie - patrz Uprawnienia administratorów), ochrony skrzynek pocztowych i komputerów obsługi.
- Nie weryfikujemy konfiguracji pod kątem zgodności z prawem - wymagania RODO, polityka prywatności i procedury obsługi incydentów ustala sklep.
- Dwuetapowe logowanie dla klientów sklepu, np. dla kont firmowych B2B.
- Klucze sprzętowe i passkeys przy logowaniu do panelu.
- Polityka źródeł treści dopasowana do skryptów danego sklepu i osobne ustawienia dla środowiska testowego i produkcyjnego.
- Powiadomienie e-mail o logowaniu do panelu z nowego urządzenia.
- Raport bezpieczeństwa w panelu - kto ma włączone 2FA, aktywne klucze API oraz zbiorcze zestawienie ostatnich logowań (dziś data ostatniego logowania jest widoczna przy każdym koncie administratora).
Czy uruchomienie zabezpieczeń wymaga zmian w kodzie sklepu?
Nie w większości przypadków. Mechanizmy są częścią platformy - uruchomienie to konfiguracja i włączenie w panelu, zwykle kilka godzin, a nie projekt budowany od podstaw.
Czy dwuetapowe logowanie (2FA) obejmuje też klientów sklepu?
Nie. 2FA dotyczy panelu administracyjnego. Klienci sklepu logują się hasłem (lub przez Google, jeśli moduł jest włączony).
Ile trwa uruchomienie pełnego pakietu zabezpieczeń?
Od 8 h w szablonie Bootstrap 5 lub od 10 h w Bootstrap 4. Poszczególne mechanizmy można też uruchamiać osobno, np. samo 2FA od 1 h.
Czy klucze REST API i MCP są chronione dwuetapowym logowaniem?
Nie. 2FA nie obejmuje dostępu przez klucz REST API i MCP - takie klucze trzeba chronić jak hasła i usuwać po zakończeniu współpracy.
Czy ochrona przed podszywaniem się pod formularze (CSRF) może zablokować integracje sklepu?
Może, jeśli zostanie włączona bez przygotowania. Dlatego wdrażamy ją z obserwacją ruchu i uwzględnieniem zewnętrznych usług (płatności, kurierzy, ERP), a nie samym włącznikiem.
Czy sklep na środowisku testowym jest widoczny w wyszukiwarkach?
Nie. Sklep testowy jest dostępny tylko dla osób z linkiem dostępowym - pozostałe wejścia, w tym roboty wyszukiwarek, są przekierowywane.
Chcesz sprawdzić, które zabezpieczenia są aktywne w Waszym sklepie? Umów bezpłatną prezentację.
- Konfiguracja w panelu: Konfiguracja -> Ustawienia:
- grupa Dwuetapowa autoryzacja administratora - globalny włącznik 2FA, zaufane przeglądarki i ich ważność, weryfikacja wersji przeglądarki, blokada po błędnych kodach,
- grupa Bezpieczeństwo - Filtr CSRF (sklep), Filtr CSRF (admin), Nagłówki bezpieczeństwa,
- grupa Klienci - Weryfikuj Sesje Użytkowników, Odśwież id sesji po zalogowaniu i wylogowaniu,
- grupa Administracja - Weryfikuj Sesje Administratorów,
- grupa Passwords - ustawienia siły haseł,
- grupa reCaptcha,
- grupa Zarządzanie trybem testowym - dostęp do sklepu testowego i adres przekierowania.
- Konto administratora: Konfiguracja -> Administratorzy, sekcja Dwuetapowa autoryzacja - wybór metody, aplikacja uwierzytelniająca, cofnięcie zaufanych przeglądarek, odblokowanie konta.
- Role i uprawnienia: Konfiguracja -> Role (Uprawnienia administratorów).
- Historia: Status -> Historia (Historia zmian).
Dostęp kluczem lub kontem API, z uprawnieniami konta w panelu (REST API). Klucze MCP korzystają z tych samych uprawnień co konto w panelu i - tak jak dostęp przez REST API - nie są objęte dwuetapowym logowaniem (zobacz Ograniczenia).
Szablony maili zmienia się w Szablonach maili i alertach, komunikaty sklepu - w Edytorze komunikatów.
| Alert |
Odbiorca |
Kiedy |
admin2FACodeEmailAlert (szablon admin2FACodeEmail) |
administrator |
logowanie do panelu z metodą "kod z e-maila" |
Szablon zakłada się sam przy uruchomieniu modułu, w wersji polskiej i angielskiej. Zmienne w szablonie: $code - kod weryfikacyjny, $ttlMinutes - ważność kodu w minutach, $userSymbol - login administratora.
Komunikat msg.passwordStrength.custom opisuje wymagania dla własnej reguły siły hasła (wyświetlany pod polem hasła).