Jak sprawdzić bezpieczeństwo strony internetowej bez hakowania

Wiele elementów zabezpieczeń sklepu internetowego możesz sprawdzić z zewnątrz, odczytując to, co strona i tak wysyła każdemu odwiedzającemu: certyfikat TLS, przekierowania, nagłówki odpowiedzi HTTP, pliki cookie, ładowane skrypty i publiczne rekordy DNS. Takie pasywne testy nie wysyłają ruchu atakującego i nie wymagają logowania, więc obciążają sklep nie bardziej niż zwykła wizyta. Wychwytują luki w konfiguracji, takie jak wygasający certyfikat, brak HSTS, niezabezpieczone pliki cookie, mieszana zawartość (mixed content) czy wersja jQuery ze znanymi podatnościami. Nie są testem penetracyjnym i nie mogą dowieść, że sklep jest bezpieczny.

Najważniejsze w skrócie

• Publicznie zaufane certyfikaty TLS wydane od 15 marca 2026 roku mogą być ważne najwyżej 200 dni; w marcu 2027 roku limit spadnie do 100 dni, a w marcu 2029 roku do 47 dni (CA/Browser Forum (otwiera się w nowej karcie)).
• Przeglądarki ignorują nagłówek HSTS, jeśli zostanie wysłany przez zwykłe HTTP (MDN (otwiera się w nowej karcie)).
• Dyrektywa CSP frame-ancestors nie działa w tagu <meta>; musi zostać wysłana jako nagłówek odpowiedzi (MDN (otwiera się w nowej karcie)).
• Wersje jQuery starsze niż 3.5.0 są podatne na dwie luki XSS, a jedną z nich, CVE-2020-11023, agencja CISA dodała 23 stycznia 2025 roku do katalogu Known Exploited Vulnerabilities (NVD (otwiera się w nowej karcie)).
• Plik security.txt musi zawierać pola Contact i Expires i znajdować się pod adresem /.well-known/security.txt (RFC 9116 (otwiera się w nowej karcie)).

Co uznaje się za pasywny test bezpieczeństwa?

Test pasywny jedynie odczytuje to, co strona lub jej DNS zwracają w odpowiedzi na zwykłe żądanie.

Oznacza to wczytywanie publicznych stron, odczytywanie certyfikatu i nagłówków odpowiedzi, sprawdzanie, jakie pliki cookie i skrypty ustawia strona, oraz odpytywanie publicznych rekordów DNS. Test pasywny nie zgaduje haseł, nie wysyła ładunków typu injection, nie sonduje adresów panelu administracyjnego i nie skanuje portów. Wszystko, co opisujemy poniżej, możesz zrobić za pomocą przeglądarki oraz narzędzi curl, openssl i dig.

Jak sprawdzić certyfikat TLS i datę jego wygaśnięcia?

Odczytaj bezpośrednio daty i nazwy w certyfikacie i upewnij się, że jego odnawianie jest zautomatyzowane.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Sprawdź, czy data notAfter przypada z dużym zapasem w przyszłości, czy certyfikat obejmuje zarówno example.com, jak i www.example.com, jeśli używasz obu (nazwy pokazuje podgląd certyfikatu w przeglądarce), i czy przeglądarka nie wyświetla ostrzeżeń. Okresy ważności certyfikatów skracają się zgodnie z Baseline Requirements organizacji CA/Browser Forum (sekcja 6.3.2, wersja 2.3.1 według stanu na październik 2026 roku), w następstwie głosowania SC-081v3 (otwiera się w nowej karcie) przyjętego 11 kwietnia 2025 roku:

Przy krótkich okresach ważności ręczne odnawianie jest ryzykowne, więc upewnij się, że Twój hosting lub narzędzie do obsługi certyfikatów odnawia je automatycznie. Sprawdź też, czy zwykłe HTTP przekierowuje na HTTPS:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

Oczekiwany wynik to odpowiedź 301 (lub 308) z nagłówkiem location zaczynającym się od https://.

Jakie nagłówki bezpieczeństwa powinien wysyłać sklep internetowy?

Niewielki zestaw nagłówków odpowiedzi blokuje typowe ataki po stronie przeglądarki niemal bez kosztów.

Sprawdź, co wysyła Twój sklep:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Dwie przestrogi. includeSubDomains blokuje każdą subdomenę, która działa tylko przez HTTP, więc najpierw sprawdź subdomeny. Wpisanie na listę HSTS preload wymaga max-age wynoszącego co najmniej 31536000 oraz includeSubDomains, więc dodawaj preload dopiero wtedy, gdy każda subdomena jest gotowa na HTTPS. Pełna polityka CSP ograniczająca skrypty jest warta wdrożenia, ale OWASP zaznacza, że jej konfiguracja i utrzymanie są złożone, a sklepy z wieloma aplikacjami muszą ją starannie przetestować.

Czy Twoje pliki cookie mają atrybuty Secure, HttpOnly i SameSite?

Pliki cookie sesji i koszyka powinny mieć wszystkie trzy atrybuty, a zobaczysz je w nagłówkach odpowiedzi Set-Cookie.

Jeśli atrybut SameSite nie jest ustawiony, przeglądarki traktują plik cookie jak Lax. Pliki cookie, które muszą odczytywać Twoje własne skrypty, nie mogą mieć atrybutu HttpOnly, więc skup się na tych, które identyfikują zalogowanego klienta lub administratora.

curl -sI https://example.com/ | grep -i "^set-cookie"

Narzędzia deweloperskie przeglądarki pokazują te same informacje, w tym pliki cookie ustawiane przez skrypty po wczytaniu strony.

Jak znaleźć mieszaną zawartość (mixed content)?

Mieszana zawartość to każdy zasób ładowany przez HTTP na stronie serwowanej przez HTTPS, a konsola przeglądarki wyświetla jej listę.

MDN (otwiera się w nowej karcie) dzieli ją na dwie grupy. Obrazy, dźwięk i wideo to zasoby „możliwe do podniesienia” (upgradable): przeglądarki automatycznie pobierają je przez HTTPS. Skrypty, arkusze stylów, ramki iframe, czcionki i żądania fetch() to zasoby „blokowalne” (blockable): przeglądarki je blokują, co psuje wszystko, co od nich zależało. Podniesione żądania kierowane na sam adres IP również są blokowane.

Aby ją znaleźć, otwórz konsolę na kluczowych szablonach (strona główna, kolekcja, produkt, koszyk) i przeszukaj kod motywu, treść stron i ustawienia aplikacji pod kątem http://. Centrum pomocy Shopify podaje, że każda strona sklepu z zasobem, który nie jest dostarczany przez HTTPS, jest uznawana za niezabezpieczoną (otwiera się w nowej karcie), i zaleca hostowanie zasobów w Shopify lub serwowanie ich przez HTTPS. W WooCommerce sprawdź treść starszych wpisów i opcje motywu, jeśli witryna kiedykolwiek działała na http://.

Jak wykryć przestarzałe biblioteki JavaScript ze znanymi CVE?

Sporządź listę bibliotek ładowanych przez każdą stronę, odczytaj ich wersje i porównaj je z bazą National Vulnerability Database.

Zacznij od jQuery. W konsoli przeglądarki $.fn.jquery zwraca wczytaną wersję (jQuery API (otwiera się w nowej karcie)). Wersje, które należy oznaczyć:

Oba problemy z 2020 roku naprawiono w jQuery 3.5.0. Podatna wersja oznacza, że wadliwy kod jest obecny; to, czy da się go wykorzystać, zależy od tego, jak strona przekazuje do niego dane. WordPress zawiera jQuery 3.5.1 od wersji 5.6 (otwiera się w nowej karcie), więc stary jQuery w sklepie WooCommerce wskazuje na przestarzałego WordPressa albo na motyw lub wtyczkę, które ładują własną kopię. W Shopify sprawdź pliki motywu i aplikacje, które wstrzykują skrypty.

Czym jest security.txt i czy Twój sklep go potrzebuje?

To zwykły plik tekstowy, który informuje badaczy bezpieczeństwa, jak zgłosić Ci podatność.

RFC 9116 (otwiera się w nowej karcie) (kwiecień 2022 roku; to RFC informacyjne, więc stosowanie go jest dobrowolne) stanowi, że plik musi być serwowany przez HTTPS pod adresem /.well-known/security.txt jako text/plain. Pola Contact i Expires są wymagane, a RFC zaleca datę Expires przypadającą za mniej niż rok.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

W WooCommerce możesz umieścić plik na swoim serwerze. Na platformie hostowanej sprawdź, czy możesz opublikować plik pod tą ścieżką; jeśli nie, wyraźnie opisany kontakt w sprawach bezpieczeństwa na stronie kontaktowej też jest pomocny.

Jak DMARC chroni sklep przed podszywaniem się pod jego adres e-mail?

DMARC pozwala poprosić dostawców poczty o umieszczenie w kwarantannie lub odrzucenie wiadomości, które używają Twojej domeny w adresie From, a nie przechodzą zgodnej weryfikacji SPF ani DKIM.

Rekord z p=none jedynie zbiera raporty; nie zatrzymuje sfałszowanych wiadomości. Klienci oczekują potwierdzeń zamówień i wiadomości o resetowaniu hasła z Twojej domeny, więc warto blokować wiadomości phishingowe, które pokazują dokładnie Twoją domenę. Sprawdź swoją politykę poleceniem dig +short TXT _dmarc.example.com, a specyfikację znajdziesz w RFC 9989 (otwiera się w nowej karcie). DMARC nie obejmuje domen łudząco podobnych, tylko domenę, która publikuje rekord.

Czym zarządza Shopify, a co kontrolujesz w WooCommerce?

Shopify utrzymuje serwery obsługujące jego sklepy, a w samodzielnie hostowanym sklepie WooCommerce ustawienia serwera należą do Ciebie i Twojego dostawcy hostingu.

Gdy w październiku 2026 roku sprawdziliśmy kilka sklepów hostowanych przez Shopify, ich odpowiedzi zawierały HSTS z max-age wynoszącym około 91 dni, X-Content-Type-Options: nosniff oraz politykę CSP z upgrade-insecure-requests, natomiast frame-ancestors różniło się między sklepami. Shopify podaje, że ma certyfikat zgodności z PCI DSS na poziomie 1 (otwiera się w nowej karcie). Za motyw i zainstalowane aplikacje nadal odpowiadasz Ty.

W przypadku WooCommerce przewodnik po zabezpieczaniu WordPressa (otwiera się w nowej karcie) zaleca aktualizowanie WordPressa i wtyczek, usuwanie nieużywanych wtyczek i zapytanie dostawcy hostingu, jakie środki bezpieczeństwa stosuje.

Dlaczego to nie jest test penetracyjny?

Test penetracyjny aktywnie próbuje przeprowadzać ataki; testy pasywne jedynie obserwują.

NIST SP 800-115 definiuje testy penetracyjne jako testy bezpieczeństwa, w których oceniający naśladują rzeczywiste ataki, aby znaleźć sposoby obejścia zabezpieczeń systemu (słownik NIST (otwiera się w nowej karcie)). Testy pasywne nie widzą luk po stronie serwera we wtyczkach, słabych lub powtarzanych haseł administratorów, braku uwierzytelniania dwuskładnikowego, błędów kontroli dostępu ani podatnego kodu, który nigdy nie pojawia się w źródle strony. Traktuj je jako punkt odniesienia, który możesz powtórzyć w dowolnym momencie. Jeśli potrzebujesz głębszej pewności, zleć test penetracyjny z pisemnie określonym zakresem, na systemach, które należą do Ciebie lub do których testowania masz uprawnienia.

Bezpłatny skan przeprowadza pierwszą rundę kontroli Twojego sklepu. Raport bezpieczeństwa strony obejmuje pasywne testy opisane w tym artykule, od TLS i przekierowań po nagłówki, pliki cookie, mieszaną zawartość, przestarzałe biblioteki, security.txt i DMARC, wraz z poprawkami dla każdego wyniku. Jak każda pasywna analiza, nie może zagwarantować, że sklep jest bezpieczny.

Najczęściej zadawane pytania

Czy pasywne testy bezpieczeństwa narażają mój sklep na ryzyko?

Nie bardziej niż zwykła wizyta. Pobierają te same publiczne strony i rekordy DNS, które pobrałaby każda przeglądarka lub każdy serwer pocztowy, i nie próbują się logować ani wysyłać ładunków ataku.

Czy w Shopify można dodać nagłówki bezpieczeństwa?

Nagłówki odpowiedzi sklepu pochodzą z serwerów Shopify, więc jeśli brakuje nagłówka, którego potrzebujesz, skontaktuj się z pomocą techniczną Shopify. Tag CSP <meta> w motywie może dodać niektóre dyrektywy, ale MDN zaznacza, że frame-ancestors nie jest obsługiwane w <meta>.

Czy stara wersja jQuery oznacza, że mój sklep został zhakowany?

Nie. Oznacza, że ładowany jest kod ze znanymi podatnościami, co zwiększa ryzyko, jeśli strona przekazuje niezaufany kod HTML do podatnych metod. Zaktualizuj bibliotekę albo usuń motyw lub wtyczkę, które ją ładują.

Jak długo może być obecnie ważny certyfikat TLS?

Publicznie zaufane certyfikaty wydane od 15 marca 2026 roku mogą być ważne najwyżej 200 dni. Od 15 marca 2027 roku limit spada do 100 dni, a od 15 marca 2029 roku do 47 dni.

Czy plik security.txt jest obowiązkowy?

RFC 9116 to RFC informacyjne, więc w świetle tego standardu publikacja pliku jest dobrowolna. Opublikowanie go niewiele kosztuje, a badacze zyskują jasny sposób kontaktu z Tobą.

Czy czysty wynik pasywnego skanu oznacza, że mój sklep jest bezpieczny?

Nie. Pokazuje tylko, że publiczna konfiguracja wygląda poprawnie. Podatności po stronie serwera, bezpieczeństwo kont i błędy w logice biznesowej wymagają innych testów.

Źródła

• Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.3.1 (otwiera się w nowej karcie), CA/Browser Forum, 4 października 2026
• Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (otwiera się w nowej karcie), CA/Browser Forum, 11 kwietnia 2025
• Strict-Transport-Security (otwiera się w nowej karcie), MDN Web Docs, ostatnia zmiana 11 września 2026
• CSP: frame-ancestors (otwiera się w nowej karcie), MDN Web Docs, ostatnia zmiana 27 sierpnia 2026
• X-Content-Type-Options (otwiera się w nowej karcie), MDN Web Docs, ostatnia zmiana 17 marca 2026
• Using HTTP cookies (otwiera się w nowej karcie), MDN Web Docs, ostatnia zmiana 17 września 2026
• Mixed content (otwiera się w nowej karcie), MDN Web Docs, ostatnia zmiana 15 sierpnia 2026
• HTTP Security Response Headers Cheat Sheet (otwiera się w nowej karcie), OWASP Cheat Sheet Series, dostęp 22 października 2026
• CVE-2020-11022 (otwiera się w nowej karcie), NIST National Vulnerability Database, opublikowano 29 kwietnia 2020
• CVE-2020-11023 (otwiera się w nowej karcie), NIST National Vulnerability Database, opublikowano 29 kwietnia 2020
• CVE-2019-11358 (otwiera się w nowej karcie), NIST National Vulnerability Database, opublikowano 20 kwietnia 2019
• .jquery (otwiera się w nowej karcie), dokumentacja jQuery API, dostęp 22 października 2026
• Updating core jQuery to version 3, part 2 (otwiera się w nowej karcie), Make WordPress Core, 5 listopada 2020
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (otwiera się w nowej karcie), IETF, kwiecień 2022
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (otwiera się w nowej karcie), IETF, maj 2026
• Enabling secure connections to your Shopify store (otwiera się w nowej karcie), Shopify Help Center, dostęp 22 października 2026
• Security (otwiera się w nowej karcie), Shopify, dostęp 22 października 2026
• Hardening WordPress (otwiera się w nowej karcie), WordPress Developer Resources, dostęp 22 października 2026
• Penetration testing (glossary) (otwiera się w nowej karcie), NIST Computer Security Resource Center, z powołaniem na NIST SP 800-115 (wrzesień 2008), dostęp 22 października 2026