Co to są Security Headers?
Autor: Redakcja Domeny.ForSale Opublikowano
W skrócie: Security Headers to nagłówki odpowiedzi HTTP, które przekazują przeglądarce zasady bezpiecznego obsługiwania strony. Pomagają ograniczać m.in. uruchamianie niepożądanych skryptów, osadzanie strony w obcych ramkach i ujawnianie informacji przy przechodzeniu między witrynami. Nie zastępują bezpiecznego kodu ani aktualizacji, ale stanowią dodatkową warstwę ochrony.
Jak działają nagłówki bezpieczeństwa
Gdy przeglądarka pobiera stronę, serwer wysyła jej treść oraz metadane, czyli informacje opisujące odpowiedź. Nagłówki HTTP są częścią tych metadanych. Nie pojawiają się w tekście strony, ale przeglądarka może na ich podstawie ograniczyć sposób korzystania z otrzymanych zasobów.
Nagłówki bezpieczeństwa mogą nakazywać używanie szyfrowanego połączenia, wskazywać dozwolone źródła skryptów albo zabraniać osadzania strony w ramce innej witryny. Ustawia się je zwykle w konfiguracji serwera, aplikacji, reverse proxy lub CDN, czyli infrastruktury pośredniczącej w dostarczaniu treści.
To zabezpieczenia egzekwowane przede wszystkim przez przeglądarkę. Nie uniemożliwiają bezpośredniego wysyłania żądań do aplikacji innymi narzędziami, dlatego nie zastępują sprawdzania uprawnień na serwerze.
Najważniejsze Security Headers i ich zastosowania
Nie istnieje jeden zestaw ustawień odpowiedni dla każdej strony. Poniższe nagłówki odpowiadają za różne zagrożenia i wymagają dopasowania do działania serwisu.
| Nagłówek | Do czego służy | Na co uważać |
|---|---|---|
Content-Security-Policy | Określa m.in. dozwolone źródła skryptów, stylów i innych zasobów. | Zbyt restrykcyjna polityka może zablokować formularz, płatności lub analitykę. |
Strict-Transport-Security | Nakazuje przeglądarce korzystanie z HTTPS przez wskazany czas. | Długi okres obowiązywania i objęcie subdomen wymagają przygotowania całej infrastruktury. |
X-Content-Type-Options | Przy wartości nosniff ogranicza zgadywanie typu zasobu niezgodnie z deklaracją serwera. | Serwer musi wysyłać poprawny Content-Type, np. dla skryptów i arkuszy stylów. |
Referrer-Policy | Kontroluje, jakie informacje o adresie strony są przekazywane w nagłówku Referer. | Ustawienie powinno uwzględniać prywatność i potrzeby integracji. |
Permissions-Policy | Ogranicza dostęp do wybranych funkcji przeglądarki, np. kamery lub geolokalizacji. | Obsługa poszczególnych dyrektyw zależy od przeglądarki. |
X-Frame-Options | Ogranicza osadzanie strony w ramkach. | Ma mniej elastyczne możliwości niż dyrektywa frame-ancestors w CSP. |
CSP, czyli Content Security Policy, pomaga ograniczać skutki XSS — ataków polegających na uruchomieniu niepożądanego kodu w kontekście strony. Sama lista zaufanych domen nie zapewnia pełnej ochrony: znaczenie mają konkretne dyrektywy, sposób ładowania skryptów i brak nadmiernie szerokich wyjątków.
Ochronę przed clickjackingiem, czyli nakłanianiem użytkownika do kliknięcia elementu strony ukrytej w obcej witrynie, zapewnia m.in. dyrektywa frame-ancestors w CSP. Może ona całkowicie zabronić osadzania strony albo dopuścić tylko wskazane witryny.
Przykład: strona z formularzem i zewnętrznymi usługami
Załóżmy, że firmowa strona korzysta z formularza kontaktowego, mapy i zewnętrznego narzędzia analitycznego. Wprowadzenie CSP dopuszczającej wyłącznie zasoby z własnej domeny może wyłączyć mapę i analitykę. Dlatego przed wdrożeniem trzeba ustalić, skąd strona pobiera skrypty, style, obrazy i ramki oraz dokąd wysyła żądania.
Jeśli serwis nie powinien być osadzany w żadnej ramce, przykładowy fragment polityki wygląda tak:
Content-Security-Policy: frame-ancestors 'none'
To wyłącznie reguła dotycząca osadzania, a nie kompletna polityka CSP. Nie ogranicza źródeł skryptów ani połączeń sieciowych. Gdy strona ma już CSP, regułę należy świadomie połączyć z istniejącą konfiguracją, zamiast bez sprawdzenia dokładać kolejną politykę.
Dla strony, która nie potrzebuje kamery ani mikrofonu, można rozważyć:
Permissions-Policy: camera=(), microphone=()
Tego ustawienia nie należy kopiować do aplikacji prowadzącej wideorozmowy. Dobry nagłówek ogranicza niepotrzebne możliwości, a nie funkcje niezbędne użytkownikowi.
Jak sprawdzić i bezpiecznie wdrożyć nagłówki
Najprościej otworzyć narzędzia deweloperskie przeglądarki, przejść do zakładki sieciowej, odświeżyć stronę i wybrać żądanie głównego dokumentu. W sekcji nagłówków odpowiedzi można sprawdzić, co faktycznie otrzymała przeglądarka. Sama obecność wpisu w konfiguracji serwera nie oznacza jeszcze, że dociera on do użytkownika.
Praktyczna kolejność wdrożenia:
- Sprawdź reprezentatywne adresy: stronę główną, logowanie, formularze i strony błędów. Odpowiedzi mogą przechodzić przez różne warstwy infrastruktury.
- Ustal, gdzie zarządzasz nagłówkami. Aplikacja, serwer i CDN nie powinny przypadkowo nadpisywać ustawień ani dodawać sprzecznych reguł.
- Przygotuj CSP w trybie
Content-Security-Policy-Report-Only. Pozwala obserwować naruszenia bez blokowania zasobów; zbieranie raportów wymaga dodatkowej konfiguracji. - Przetestuj kluczowe czynności użytkownika, w tym logowanie, wysłanie formularza i płatność, jeśli występuje.
- Włącz egzekwowanie polityki i obserwuj błędy po wdrożeniu.
HSTS, czyli mechanizm uruchamiany przez Strict-Transport-Security, wdrażaj dopiero przy sprawnie działającym HTTPS. Parametr includeSubDomains obejmuje także subdomeny, więc przed jego użyciem sprawdź również mniej oczywiste usługi. Aktualną składnię i obsługę dyrektyw potwierdź w oficjalnej dokumentacji używanej platformy oraz przeglądarek.
Czego nie mówi wynik skanera bezpieczeństwa
Skaner może wykryć brak nagłówka lub ryzykowną wartość, ale jego ocena nie dowodzi bezpieczeństwa aplikacji. Niektóre polityki są potrzebne tylko w określonych zastosowaniach, a dodawanie ich dla lepszego wyniku może zepsuć integracje.
Nagłówki nie naprawią błędnych uprawnień, podatności bazy danych ani wycieku sekretów w kodzie. Zacznij od sprawdzenia rzeczywistych odpowiedzi swojej strony i wybierz jedną zmianę, której działanie potrafisz zweryfikować przed publikacją.
Zobacz też: Co to jest CSP?
Przeczytaj także
