Przetestuj nagłówki bezpieczeństwa swojej strony

Najłatwiej pokazać to na przykładzie ramki. Stronę bez ochrony przed osadzeniem można wczytać w tle cudzej witryny i przykryć niewidoczną nakładką: odwiedzający myśli, że klika w konkurs, a naprawdę klika w Twoim panelu albo sklepie. Ten atak nazywa się clickjacking i wyłącza go jedna linijka konfiguracji serwera.

Podobnie działa Content-Security-Policy. Jeżeli ktoś zdoła wstrzyknąć na stronę obcy skrypt, na przykład przez lukę we wtyczce albo w polu komentarza, CSP ogranicza, co ten skrypt może zrobić i dokąd może wysłać dane. Bez CSP wstrzyknięty skrypt ma pełną swobodę, z dostępem do sesji zalogowanych użytkowników włącznie.

Sprawdzamy wyłącznie to, co serwer wysyła w odpowiedzi na zwykłe zapytanie, takie samo, jakie wysyła każda przeglądarka. Nie próbujemy niczego łamać, nie wstrzykujemy danych i nie testujemy formularzy. Wynik mówi, czy zabezpieczenie jest ustawione, a nie czy stronę da się w praktyce zaatakować.

Oceniamy przy tym stan faktyczny, nie listę życzeń. Test uwzględnia nowsze odpowiedniki starych nagłówków, pomija zalecenia, które w Twojej konfiguracji nie mają zastosowania, i odróżnia serwer, który podaje samą nazwę platformy, od takiego, który zdradza dokładny numer wersji.

Nagłówki ustawia się w konfiguracji serwera albo hostingu: w pliku .htaccess na Apache, w konfiguracji nginx, czasem w panelu hostingu. Na WordPressie część nagłówków potrafią dołożyć wtyczki bezpieczeństwa, choć konfiguracja na poziomie serwera jest czystsza i szybsza.

Kolejność ma znaczenie. Zacznij od nagłówków, które niczego nie zepsują, jak X-Content-Type-Options i ochrona przed ramkami. Content-Security-Policy zostaw na koniec i wdrażaj najpierw w trybie raportowania, bo zbyt restrykcyjna polityka potrafi wyłączyć skrypty, z których strona naprawdę korzysta.