Bezpieczeństwo strony internetowej to nie tylko kwestia hakerów i filmów szpiegowskich. To codzienna rzeczywistość każdego właściciela witryny: wyciek danych klientów, kara UODO za brak RODO, lub po prostu Google który przestaje indeksować Twoją stronę z powodu braku HTTPS. Dobra wiadomość: sprawdzenie podstawowych parametrów bezpieczeństwa zajmuje mniej niż minutę.
Czego wymaga dobry audyt bezpieczeństwa strony?
Profesjonalny audyt bezpieczeństwa strony WWW sprawdza kilka warstw jednocześnie. Każda z nich może być niezależnym wektorem ataku lub źródłem problemów z RODO i SEO.
- SSL/TLS - certyfikat, wersja protokołu (TLS 1.0/1.1 są przestarzałe), data wygaśnięcia
- Nagłówki HTTP - HSTS, Content Security Policy, X-Frame-Options, X-Content-Type
- DNS i email security - SPF, DKIM, DMARC, MTA-STS, BIMI
- Otwarte porty - bazy danych dostępne z internetu bez hasła (Redis, MongoDB, MySQL)
- Wycieki sekretów - klucze API zakodowane w bundle JavaScript
- Ukryte pliki - .env, .git/config, wp-config.php publicznie dostępne
- Zgodność z RODO - cookies, polityka prywatności, Google Analytics bez zgody
Krok 1: Sprawdź certyfikat SSL i protokół TLS
HTTPS to absolutne minimum w 2025 roku. Ale sam certyfikat to za mało - liczy się też wersja protokołu TLS. TLS 1.0 i TLS 1.1 są oficjalnie zdeprecjonowane przez IETF (RFC 8996) i podatne na ataki BEAST i POODLE. Sprawdź czy Twoja strona używa wyłącznie TLS 1.2 lub 1.3.
Wskazówka - Narzędzie: Wpisz adres swojej strony w Wirtualna Tarcza lub użyj testssl.sh (narzędzie open-source). Wynik pokazuje dokładnie które szyfry i protokoły są aktywne.
Krok 2: Nagłówki HTTP bezpieczeństwa
Nagłówki HTTP to pierwsza linia obrony przed atakami XSS, clickjacking i wstrzykiwaniem treści. Brak nagłówków bezpieczeństwa to jedna z najczęstszych przyczyn niskiego wyniku w audytach. Sprawdź, czy Twoja strona zwraca:
- Strict-Transport-Security (HSTS) - wymusza HTTPS nawet gdy użytkownik wpisze 'http://'
- Content-Security-Policy (CSP) - blokuje wykonywanie nieautoryzowanych skryptów (XSS)
- X-Frame-Options: DENY - chroni przed atakami clickjacking
- X-Content-Type-Options: nosniff - blokuje MIME sniffing
- Referrer-Policy - kontroluje jakie dane są wysyłane przy kliknięciu linku
- Permissions-Policy - ogranicza dostęp do kamery, mikrofonu, geolokalizacji
Wskazówka - Brak CSP to automatycznie ocena C lub niżej w większości skanerów. Brak HSTS to ryzyko downgrade attacks na stronach bankowych.
Krok 3: Bezpieczeństwo email - SPF, DKIM, DMARC
Bez poprawnych rekordów DNS Twoja domena może być użyta do wysyłania phishingowych maili w Twoim imieniu. Jeśli ktoś wyśle maila 'od' twoja-firma.pl do klientów z prośbą o przelew - i nie masz DMARC - Twoje serwery pocztowe mogą to zaakceptować.
- SPF (Sender Policy Framework) - lista serwerów uprawnionych do wysyłania maili z Twojej domeny
- DKIM (DomainKeys Identified Mail) - kryptograficzny podpis każdej wiadomości
- DMARC - polityka co zrobić z mailem który nie przejdzie SPF/DKIM (odrzuć, poddaj kwarantannie, przyjmij)
- MTA-STS - wymusza TLS przy dostarczaniu maili do Twojej domeny
- BIMI - dodaje Twoje logo do maili w Gmail i Yahoo (wymaga DMARC w trybie enforce)
Wskazówka - Sprawdź DMARC swojej domeny wpisując w terminalu: dig TXT _dmarc.twojadomena.pl. Jeśli wynik zawiera p=none - to znaczy że zbierasz raporty ale nie blokujesz fałszywych maili.
Krok 4: Otwarte porty i bazy danych bez hasła
To brzmi absurdalnie, ale kilkanaście procent instancji MongoDB i Redis dostępnych w internecie nie ma ustawionego hasła. Atakujący scanują całą pulę adresów IPv4 w ciągu godzin. Jeśli Twoja baza danych nasłuchuje na porcie 27017 (MongoDB), 6379 (Redis) lub 9200 (Elasticsearch) bez uwierzytelnienia - ktoś już ma dostęp do Twoich danych.
Porty wysokiego ryzyka: 3306 - MySQL 5432 - PostgreSQL 27017 - MongoDB 6379 - Redis 9200 - Elasticsearch 9090 - Prometheus (metryki) 8080 - alternatywny HTTP (często bez SSL)
Krok 5: Wycieki kluczy API w JavaScript
Każda aplikacja Next.js, React czy Vite kompiluje JavaScript do pliku bundle.js dostępnego publicznie. Jeśli przypadkowo umieściłeś klucz Stripe, OpenAI, Supabase lub AWS w kodzie komponentu (zamiast w zmiennej środowiskowej server-side) - każdy może go wyciągnąć klikając F12 w przeglądarce.
Wskazówka - Zasada: każdy klucz zaczynający się od NEXT_PUBLIC_ jest widoczny publicznie. Klucze do APIs które wymagają poufności (Stripe secret key, database URL, service role key Supabase) muszą być w zmiennych bez prefiksu NEXT_PUBLIC_ i używane wyłącznie server-side.
Jak szybko sprawdzić bezpieczeństwo swojej strony?
Najszybsza droga to narzędzie które sprawdza wszystkie warstwy jednocześnie. Wirtualna Tarcza analizuje SSL, nagłówki, DNS, porty, wycieki sekretów, ukryte pliki i zgodność z RODO w jednym skanie - wynik A–F pojawia się w 5 minut. Możesz też zacząć od bardziej szczegółowych narzędzi dla konkretnych obszarów, ale to kilka godzin pracy zamiast kilku minut.
- Wirtualna Tarcza - pełny skan 10 modułów w 5 minut, po polsku
- Mozilla Observatory - nagłówki HTTP i CSP (obserwatorium.mozilla.org)
- MXToolbox - sprawdzenie SPF, DKIM, DMARC
- testssl.sh - lokalne narzędzie CLI do SSL/TLS
- Shodan.io - sprawdzenie otwartych portów (wymaga konta)
Jak interpretować wynik audytu?
Większość narzędzi używa skali A–F lub 0–100. Wynik A (90–100 pkt) oznacza solidną konfigurację bezpieczeństwa. Wynik D lub F (poniżej 60 pkt) to sygnał że strona ma poważne luki wymagające natychmiastowej interwencji. Nie wszystkie luki są równie krytyczne:
- Critical/High - wymaga naprawy natychmiast (otwarta baza, wyciek klucza)
- Medium - ważne do naprawy w ciągu tygodnia (brak CSP, brak DMARC)
- Low - dobre praktyki, napraw przy następnym deploymencie (brak Referrer-Policy)
- Info - informacja bez negatywnego wpływu (wykryta platforma, stack technologiczny)