ShieldWave

Wszystkie artykuły

Jak zabezpieczone są najpopularniejsze polskie strony? Pomiar 1000 domen .pl (wrzesień 2026)

24 września 2026 r. sprawdziłem 1000 najpopularniejszych domen .pl. Mniej niż połowa chroni się przed podszywaniem w mailach, a co czwarta strona ma CSP.

Radek, ENSOMEDIAOpublikowano 13 min czytaniaIn English

Wziąłem pierwsze 1000 domen .pl z rankingu Tranco, który powstał do badań naukowych, i 24 września 2026 r. rano sprawdziłem je z zewnątrz, tak jak widzi je każdy odwiedzający i każdy serwer pocztowy. Pomiar był pasywny: zapytania DNS, jedna wizyta na stronie głównej i kilka połączeń TLS na domenę, bez skanowania podatności i bez prób logowania. Wyniki liczyły te same testy, które działają w darmowych narzędziach ShieldWave. Nie wymieniam żadnej ze sprawdzonych domen.

Najważniejsze liczby

  • 24 września 2026 r. politykę DMARC, która każe serwerom pocztowym odrzucać albo odkładać do spamu maile podszywające się pod domenę, miało 460 z 997 najpopularniejszych domen .pl (46,1%). Wśród domen, które odbierają pocztę (mają rekordy MX), było to 445 z 927 (48,0%).
  • Według pomiaru z 24 września 2026 r. nagłówek HSTS wysyłało 406 z 882 najpopularniejszych stron .pl działających na HTTPS (46,0%), a wymuszaną politykę Content-Security-Policy miało 217 z 887 (24,5%).
  • We wrześniu 2026 r. połączenie TLS 1.0 przyjmowało jeszcze 230 z 952 najpopularniejszych domen .pl (24,2%). Z tych 230 domen 149 działa za Cloudflare, który przyjmuje TLS 1.0, dopóki właściciel nie podniesie minimalnej wersji.
  • W 274 z 997 domen (27,5%) nie ma żadnego rekordu DMARC, a w kolejnych 248 (24,9%) rekord ma ustawienie p=none, które niczego nie blokuje.
  • W teście nagłówków bezpieczeństwa najwyższą ocenę, A, dostało 20 z 887 stron głównych (2,3%), a najniższą, F, 290 (32,7%).
  • Plik security.txt, z którego badacz dowie się, gdzie zgłosić lukę, znalazłem na co najmniej 78 z 881 stron (8,9%).
  • Spośród 46 stron, które podają w nagłówkach wersję PHP, 26 działa na wersji bez poprawek bezpieczeństwa, w tym 11 na PHP 5.

Poczta: kto może wysłać maila jako Twoja domena

Podrobiony mail z adresem Twojej firmy w polu „Od” wystarczy, żeby wysłać klientowi fałszywą fakturę. Chronią przed nim trzy wpisy w DNS domeny: SPF, DKIM i DMARC. Opisałem je w artykule SPF, DKIM i DMARC po ludzku. Rozstrzyga DMARC: mówi serwerowi odbiorcy, co zrobić z wiadomością, która podaje się za Twoją, a nie przeszła testów.

SPF jest niemal wszędzie: ma go 915 z 999 domen (91,6%). Sam SPF nie sprawdza jednak adresu, który odbiorca widzi w polu „Od”. To robi dopiero DMARC, a tu liczby są niższe.

Co rekord DMARC każe zrobić z podrobionym mailem (997 domen .pl)
  • Brak rekordu DMARC27,5%274 z 997
  • p=none: tylko obserwuje, niczego nie blokuje24,9%248 z 997
  • quarantine albo reject, ale tylko dla części maili (pct poniżej 100)1,5%15 z 997
  • quarantine albo reject dla wszystkich maili46,1%460 z 997

Domeny, dla których DNS dał jednoznaczną odpowiedź. Liczy się tylko własny rekord domeny.

Blokadę podszywania się ma więc 460 z 997 domen (46,1%). Wśród domen z rekordami MX, czyli takich, które odbierają pocztę, jest to 445 z 927 (48,0%). Pozostałe domeny albo nie mają DMARC, albo mają rekord, który tylko obserwuje. Czy podrobiona wiadomość trafi wtedy do skrzynki, zależy już wyłącznie od filtrów po stronie odbiorcy.

p=none nie jest błędem, tylko zalecanym pierwszym krokiem: domena zbiera raporty, a jej właściciel widzi, kto wysyła maile w jej imieniu. W 622 z 723 rekordów DMARC (86,0%) jest adres do raportów zbiorczych (rua). Ochrona zaczyna się jednak dopiero po przejściu na quarantine albo reject. Wśród domen, które mają DMARC, trzy ustawienia występują niemal równie często: p=none ma 248 z 723 (34,3%), quarantine 263 (36,4%), a reject 212 (29,3%).

Drobniejsze usterki SPF: 12 z 915 rekordów (1,3%) wymaga więcej niż 10 zapytań DNS, na które pozwala standard, dwie domeny mają po dwa rekordy SPF zamiast jednego, a jedna kończy rekord na +all, czyli pozwala wysyłać pocztę w swoim imieniu każdemu serwerowi.

Wyników DKIM nie podaję. Selektorów, pod którymi leżą klucze DKIM, nie da się wylistować przez DNS, więc „nie znaleziono” znaczyłoby tylko „nie ma pod popularnymi nazwami”.

Szyfrowanie: HTTPS, HSTS i TLS

Sam HTTPS to już standard. Różnice widać w tym, co go uzupełnia: w nagłówku HSTS, w starych wersjach TLS i w rekordzie CAA.

Co sprawdziłem Wynik Udział
Strona główna ładuje się z adresu https:// 882 z 887 99,4%
Certyfikat ważny, zaufany i pasujący do nazwy 919 z 953 96,4%
http:// przekierowuje na https:// 827 z 891 92,8%
w tym przekierowaniem stałym (301 albo 308) 728 z 891 81,7%
Nagłówek HSTS 406 z 882 46,0%
HSTS ważny co najmniej rok 268 z 882 30,4%
Obsługa TLS 1.3 833 z 953 87,4%
Przyjmuje połączenie TLS 1.0 230 z 952 24,2%
Rekord CAA 192 z 999 19,2%

Mianowniki się różnią, bo każdy wiersz liczy tylko domeny, dla których dany test dał odpowiedź. Szczegóły są w metodologii.

HSTS to nagłówek, który każe przeglądarce przez określony czas łączyć się z domeną wyłącznie przez HTTPS. Bez niego każde wejście na adres wpisany bez https:// zaczyna się od połączenia bez szyfrowania, zanim serwer przekieruje je na HTTPS, a w obcej sieci Wi-Fi ktoś może je przechwycić. HSTS wysyła 406 z 882 stron na HTTPS (46,0%), a z zalecanym czasem ważności co najmniej roku 268 (30,4%).

TLS 1.0 i 1.1 to stare wersje protokołu szyfrującego. Przeglądarki wyłączyły je w 2020 r., a IETF formalnie je wycofał w 2021 r. (RFC 8996). TLS 1.0 przyjmuje jeszcze 230 z 952 domen (24,2%). Odwiedzający z aktualną przeglądarką i tak połączy się przez TLS 1.2 albo 1.3, więc nie jest to droga do przejęcia strony. Serwer zgodzi się jednak na przestarzałe szyfrowanie, jeśli ktoś o nie poprosi, a o wyłączenie starych wersji pytają audytorzy i ankiety bezpieczeństwa dla dostawców.

Z tych 230 domen 149 (64,8%) działa za Cloudflare, który domyślnie przyjmuje TLS 1.0 i przestaje dopiero wtedy, gdy właściciel podniesie minimalną wersję w panelu. Reszta, czyli 81 domen, przyjmuje TLS 1.0 na własnych serwerach albo u innych dostawców.

CAA to wpis w DNS z listą urzędów certyfikacji, które mogą wystawić certyfikat dla domeny. Pozostałe urzędy muszą wtedy odmówić. Rekord CAA znalazłem przy 192 z 999 domen (19,2%).

Nagłówki bezpieczeństwa

Nagłówki bezpieczeństwa to kilka linijek instrukcji, które serwer wysyła przeglądarce razem ze stroną. Opisałem je w artykule Nagłówki bezpieczeństwa: co to jest i co zlecić programiście. Tak często pojawiają się na stronach głównych (HSTS jest w części o szyfrowaniu):

Nagłówek Stron Udział
Content-Security-Policy (wymuszana) 217 z 887 24,5%
Ochrona przed osadzaniem w ramce (X-Frame-Options albo frame-ancestors) 422 z 887 47,6%
X-Content-Type-Options: nosniff 381 z 887 43,0%
Referrer-Policy 243 z 887 27,4%
Permissions-Policy 98 z 887 11,0%

Kolejne 26 stron (2,9%) ma CSP tylko w trybie testowym Report-Only, w którym przeglądarka niczego nie blokuje.

Darmowy test nagłówków wystawia za nie ocenę od A do F. Każdy nagłówek dostaje literę, HSTS i CSP liczą się podwójnie, pozostałe pojedynczo, a średnia daje ocenę końcową. W pomiarze użyłem dokładnie tej skali.

Ocena nagłówków bezpieczeństwa stron głównych (887 stron .pl)
  • A2,3%20 z 887
  • B21,8%193 z 887
  • C21,1%187 z 887
  • D22,2%197 z 887
  • F32,7%290 z 887

Skala darmowego testu nagłówków ShieldWave. HSTS i CSP liczą się podwójnie, pozostałe nagłówki pojedynczo.

Ocena F nie znaczy, że strona ma lukę, a A nie gwarantuje, że jej nie ma. Nagłówki to druga linia obrony: ograniczają szkody, gdy zawiedzie coś innego. Ich brak zwykle oznacza domyślną konfigurację serwera, która ich nie dodaje. Często dokłada je dopiero CDN albo wtyczka.

Tego samego dnia tą samą metodą sprawdziłem po 500 najpopularniejszych domen .ae i .sa (ZEA i Arabia Saudyjska). Tamtejsze strony główne częściej mają CSP (280 z 656, czyli 42,7%) i HSTS (408 z 652, czyli 62,6%). To porównanie przybliżone: tamte listy sięgają głębiej w ranking, a 344 z 1000 stron z ZEA i Arabii Saudyjskiej nie dało się przeanalizować z Polski. Szczegóły są w omówieniu tamtego pomiaru (po angielsku).

Platformy i nieaktualne oprogramowanie

Platformę rozpoznałem na co czwartej stronie. Na 663 z 884 stron głównych (75,0%) nie znalazłem śladów żadnej znanej platformy: to strony pisane na zamówienie albo takie, które nie zdradzają, na czym działają. Udziały poniżej to więc dolne granice.

WordPressa rozpoznałem na 101 z 884 stron (11,4%). Dalej są Drupal (25 stron), Magento (21) i TYPO3 (13). Polskie platformy sklepowe (IdoSell, Shoper, AtomStore i RedCart) obsługują razem 12 stron.

Wersję WordPressa widać na 54 ze 101 stron. To małe liczby, więc podaję je bez procentów:

  • 28 z 54 nie ma najnowszego wydania 7.1.2,
  • 22 działają na starszej gałęzi niż 7.1,
  • 18 nie ma ostatniego wydania własnej gałęzi, a więc poprawek bezpieczeństwa, które dla tej gałęzi już wyszły,
  • najstarsza widoczna wersja to WordPress 3.5.1 z 2013 r.

Wersję PHP podaje w nagłówkach tylko 46 z 887 stron, więc to obraz tych 46, a nie całej sieci. Z nich 26 działa na gałęziach, które nie dostają już żadnych poprawek (8.1 i starsze), w tym 11 na PHP 5, którego ostatnia gałąź straciła wsparcie z końcem 2018 r. Kolejne 12 dostaje tylko poprawki bezpieczeństwa (8.2 i 8.3), a 8 jest w pełni wspieranych (8.4 i 8.5).

Nazwę serwera z numerem wersji, na przykład Apache/2.4.41, widać w nagłówkach 74 z 887 stron (8,3%). Samo ujawnienie wersji nie jest luką, ale podpowiada, których znanych błędów szukać.

Wtyczek w tym pomiarze nie sprawdzałem. Jeśli Twoja strona działa na WordPressie, zacznij od artykułu Nieaktualne wtyczki w WordPressie: co aktualizować, a co usunąć.

security.txt: gdzie zgłosić lukę

Plik /.well-known/security.txt (standard RFC 9116) podaje adres, pod który badacz bezpieczeństwa może zgłosić znalezioną podatność. Bez niego zgłoszenie trafia na ogólny adres kontaktowy albo nie trafia nigdzie.

Plik z polem Contact: znalazłem na 78 z 881 stron (8,9%). To dolna granica: kolejne 41 stron odpowiedziało przekierowaniem na plik security.txt pod innym adresem, a przekierowań nie śledziłem. Nawet gdyby każde z nich prowadziło do poprawnego pliku, byłoby to 119 z 881 (13,5%). Wymagane przez standard pole Expires ma 55 z 78 znalezionych plików.

Skrypty śledzące i platformy zgód

Ta część jest opisowa. Nie uruchamiałem JavaScriptu, więc widzę tylko narzędzia wymienione w kodzie HTML strony głównej. Nie wiem, czy i kiedy się uruchamiają: skrypt może czekać na zgodę odwiedzającego, a Google Tag Manager może ładować narzędzia, których w kodzie strony nie widać.

Narzędzia analityczne i reklamowe wymienione w kodzie strony głównej (884 strony .pl)
  • Google Tag Manager45,6%403 z 884
  • Google Analytics30,3%268 z 884
  • Gemius12,3%109 z 884
  • Meta Pixel10,2%90 z 884
  • Microsoft Clarity3,4%30 z 884
  • Hotjar2,5%22 z 884
  • Matomo2,0%18 z 884

W dowolnej formie: skrypt, fragment instalacyjny albo samo wywołanie. Obecność w kodzie nie mówi, czy narzędzie działa przed zgodą.

Google Analytics albo Google Tag Manager pojawia się w kodzie 572 z 884 stron (64,7%). Gemius, polski system pomiaru oglądalności, jest na 109 z 884 stron (12,3%). Tryb zgody Google (Consent Mode) z domyślną odmową, w którym narzędzia Google do czasu zgody działają bez cookies, widać na 103 z 884 stron (11,7%).

Znaną platformę do zbierania zgód, na przykład Cookiebot, OneTrust, Didomi albo platformę zgodną z IAB TCF, rozpoznałem na 293 z 884 stron (33,1%). To nie znaczy, że pozostałe strony nie mają banera. Własne banery, banery wbudowane w platformy sklepowe i narzędzia ładowane przez Google Tag Manager są dla tej metody niewidoczne. Dlatego nie wyciągam z tych liczb wniosków o zgodności z przepisami.

Co to znaczy dla Twojej firmy

Jeśli te ustawienia bywają pominięte na najpopularniejszych stronach w kraju, łatwo je przeoczyć także na mniejszej. Każdy z poniższych testów trwa minutę i nie wymaga dostępu do serwera.

  1. Poczta. Sprawdź domenę testem SPF, DKIM i DMARC. Jeśli nie masz DMARC albo masz p=none, przejdź na quarantine krok po kroku, jak w artykule SPF, DKIM i DMARC po ludzku. To ochrona przed fałszywymi fakturami wysyłanymi z Twojej domeny.
  2. Szyfrowanie. Test certyfikatu SSL pokaże ważność certyfikatu, przekierowanie na HTTPS i wersje TLS. Jeśli strona stoi za Cloudflare, minimalną wersję TLS zmienisz w panelu: SSL/TLS, Edge Certificates, Minimum TLS Version. Ustaw TLS 1.2.
  3. Nagłówki. Test nagłówków pokaże, czego brakuje. Gotowe zlecenie dla programisty jest w artykule o nagłówkach bezpieczeństwa: zacznij od HSTS z krótkim czasem ważności i CSP w trybie Report-Only.
  4. security.txt. Opublikuj plik /.well-known/security.txt z polami Contact i Expires. To kilka linijek tekstu.
  5. Oprogramowanie. Zaktualizuj CMS i wtyczki, a numery wersji usuń z nagłówków serwera. Przy WordPressie pomoże artykuł o nieaktualnych wtyczkach.
  6. Skrypty i zgody. Test cookies przed zgodą pokaże, czy strona główna zapisuje cookies śledzące albo ładuje narzędzia analityczne i reklamowe, zanim odwiedzający wyrazi zgodę. Inspektorom ochrony danych polecam też artykuł o tym, co IOD może sprawdzić na stronie klienta.

Jeśli Twoi klienci podlegają znowelizowanej ustawie o krajowym systemie cyberbezpieczeństwa, o te same ustawienia zapytają w ankiecie dla dostawców. Jak się do niej przygotować, piszę w artykule NIS2 a strona Twojej firmy.

Metodologia

Lista domen. Ranking Tranco, lista L5PV4, wygenerowana 23 września 2026 r. o 22:00 UTC z danych z 30 dni (od 25 sierpnia do 23 września 2026 r.) pięciu dostawców: Chrome UX Report, Farsight, Majestic, Cloudflare Radar i Cisco Umbrella. Tranco to ranking stworzony do badań naukowych i odporny na manipulacje. Wziąłem pierwsze 1000 domen kończących się na .pl w kolejności rankingu, razem z domenami w com.pl, gov.pl, edu.pl i innych domenach drugiego poziomu. W pierwszym milionie Tranco jest 9214 domen .pl, a wybrane zajmują w nim miejsca od 667 do 136 495. Tranco szereguje domeny, nie strony, więc na liście są też domeny techniczne (CDN, reklamy, pomiary) bez strony głównej.

Czas i miejsce. 24 września 2026 r., od 07:39 do 07:43 UTC (od 9:39 do 9:43 czasu polskiego), z jednego łącza w Polsce. Zapytania DNS szły do publicznych serwerów 1.1.1.1 i 8.8.8.8. Każde żądanie HTTP przedstawiało się jako ShieldWaveResearch/1.0 z adresem shieldwave.io; nie udawałem przeglądarki.

Co dokładnie wysłałem. Dla każdej domeny tylko:

  1. zapytania DNS: adresy, MX, TXT (SPF i DMARC), CAA,
  2. jedną wizytę na stronie głównej (https://, a gdy nie odpowiadało, http://; najwyżej 5 przekierowań),
  3. jedno żądanie http://, żeby sprawdzić przekierowanie na HTTPS,
  4. uzgodnienia TLS na porcie 443: jedno pełne i cztery próby wersji (1.0, 1.1, 1.2 i 1.3),
  5. jedno żądanie /.well-known/security.txt.

Nic więcej: żadnego szukania plików, paneli administracyjnych czy kopii zapasowych, żadnych formularzy, logowań ani ładunków testowych.

Te same testy co w darmowych narzędziach. Wyniki policzył ten sam kod, który działa w darmowych narzędziach ShieldWave (test certyfikatu, poczty, nagłówków i cookies), w wersji z commita 8db196d. Każdy może więc sprawdzić swoją domenę dokładnie tą samą miarą.

Mianowniki i wyłączenia. Każda liczba ma własny mianownik, bo nie każdy test daje odpowiedź dla każdej domeny. Z 1000 domen udało się przeanalizować 887 stron głównych. Z pozostałych 113 domen: 38 nie odpowiedziało po HTTP (13 z nich nie ma nawet adresu w DNS), 52 odpowiedziały ścianą antybotową albo blokadą, na przykład kodem 403, a 23 zwróciły inny błąd. Tych domen nie ma we wskaźnikach strony (nagłówki, HTML, security.txt, przekierowanie), ale są we wskaźnikach DNS, poczty i TLS, które od strony nie zależą. Wskaźniki DNS liczą tylko domeny, dla których odpowiedź była jednoznaczna (dla DMARC to 997 z 1000).

Definicje. DMARC blokujący podszywanie to własny rekord domeny z p=quarantine albo p=reject oraz pct=100 albo bez pct. Rekord odziedziczony po domenie nadrzędnej się nie liczy. HSTS liczę tylko na stronach, które kończą się na HTTPS, a CSP tylko w trybie wymuszanym. security.txt liczę, gdy odpowiedź ma kod 200 i pole Contact:; strona HTML nigdy się nie liczy.

Ograniczenia.

  • Tylko strona główna, jedna wizyta, stan z jednego dnia. Podstrony mogą wysyłać inne nagłówki.
  • Bez JavaScriptu: skrypty i platformy zgód odczytuję z kodu HTML. Nie widzę, co ładuje Google Tag Manager ani co skrypty zapisują później.
  • Wiele wyników to ustawienia domyślne sieci CDN albo hostingu (TLS 1.0 w Cloudflare, nagłówki dodawane albo nie na brzegu sieci).
  • Strony, które zablokowały automatyczną wizytę, wypadły ze wskaźników strony. Mogą się różnić od tych, które zostały.
  • security.txt to dolna granica, bo przekierowań nie śledziłem.
  • Rozpoznawanie platform to dolna granica (75,0% stron bez rozpoznanej platformy).
  • DKIM nie jest raportowany.
  • Pomiar z Polski: strony, które pokazują co innego w zależności od kraju odwiedzającego, gdzie indziej mogą wyglądać inaczej.

Powtarzalność i kontrola. Około kwadransa wcześniej zrobiłem pierwszy pełny przebieg dla tej samej listy. Nie publikuję go, bo po nim poprawiłem rozpoznawanie Gemiusa. Poza wskaźnikami Gemiusa żaden z 250 wskaźników nie różnił się między przebiegami o więcej niż 0,9 punktu procentowego, a mediana różnic wyniosła 0,0. Osobno sprawdziłem innymi narzędziami 36 losowo wybranych domen, w tym 20 z listy polskiej: DMARC i SPF przez inny serwer DNS (9.9.9.9), HSTS i nagłówek Server przez curl, TLS 1.0 przez openssl, security.txt przez curl. We wszystkich 216 porównaniach wynik był ten sam.

Dane. Surowych danych nie publikuję, bo zawierają nazwy domen. Do pobrania są wszystkie wskaźniki zbiorcze, każdy z licznikiem, mianownikiem, odsetkiem i opisem populacji: pl-2026-09.csv i pl-2026-09.json, na licencji CC BY 4.0. Pomiar da się powtórzyć: lista Tranco jest publiczna, a każdy test działa w darmowych narzędziach ShieldWave.

Jak cytować

Krótko: Źródło: ShieldWave, pomiar 1000 najpopularniejszych domen .pl z 24 września 2026 r., https://shieldwave.io/blog/bezpieczenstwo-polskich-stron-2026/

Pełny opis: Radosław Fedorczuk (ShieldWave, ENSOMEDIA), „Jak zabezpieczone są najpopularniejsze polskie strony? Pomiar 1000 domen .pl (wrzesień 2026)”, 24 września 2026 r., https://shieldwave.io/blog/bezpieczenstwo-polskich-stron-2026/. Dane zbiorcze na licencji CC BY 4.0.

Pytania o metodę albo dane: support@shieldwave.io.

Dane: CSV, JSON. Licencja: CC BY 4.0. Cytując, podaj ShieldWave jako źródło i link do tej strony.