Nagłówki bezpieczeństwa HTTP: kompletny przewodnik dla firm

Nagłówki bezpieczeństwa HTTP to jedno z niewielu zabezpieczeń, które kosztują kilka linii w konfiguracji serwera, a potrafią zamknąć całe klasy ataków: clickjacking, część XSS, downgrade połączenia czy wyciek adresów przez nagłówek Referer. W testach aplikacji webowych ich brak to jedno z najczęstszych znalezisk — nie dlatego, że są trudne, lecz dlatego, że nikt się nimi nie zajął. Ten przewodnik porządkuje, co wdrożyć, jak to poprawnie ustawić i jak sprawdzić efekt.

Strict-Transport-Security (HSTS)

HSTS mówi przeglądarce: „z tą domeną łącz się wyłącznie po HTTPS, nawet jeśli użytkownik wpisze http://”. Bez tego nagłówka pierwsze żądanie po HTTP może zostać przechwycone i przekierowane (atak typu SSL stripping), zanim serwer w ogóle wymusi szyfrowanie.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Trzy elementy mają znaczenie:

max-age — czas (w sekundach), przez który przeglądarka pamięta regułę. Minimum sensowne to 6 miesięcy (15552000), docelowo rok.
includeSubDomains — rozszerza regułę na wszystkie subdomeny. Bez tego atak można przenieść na login.twojafirma.pl.
preload — pozwala umieścić domenę na liście wbudowanej w przeglądarki, dzięki czemu HTTPS jest wymuszony już przy pierwszej wizycie. Wymaga zgłoszenia na hstspreload.org i jest trudny do wycofania — włączaj dopiero, gdy cała domena i subdomeny na pewno działają po HTTPS.

Częsty błąd, który wychwytujemy w skanach: HSTS obecny, ale z max-age rzędu kilku minut albo bez includeSubDomains — formalnie „jest”, realnie prawie nic nie chroni.

Content-Security-Policy (CSP)

CSP to najsilniejszy, a zarazem najtrudniejszy w konfiguracji nagłówek. Definiuje, z jakich źródeł przeglądarka może ładować skrypty, style, obrazy czy ramki. Dobrze ustawiony CSP jest ostatnią linią obrony przed cross-site scripting (XSS) — nawet jeśli atakującemu uda się wstrzyknąć skrypt, przeglądarka odmówi jego wykonania.

Problem w tym, że sama obecność nagłówka nic nie znaczy, jeśli polityka jest dziurawa:

# Słaby CSP — teoretycznie „jest", praktycznie nie chroni:
Content-Security-Policy: default-src * 'unsafe-inline' 'unsafe-eval'

'unsafe-inline' pozwala wykonać skrypty osadzone bezpośrednio w HTML — czyli dokładnie to, co robi typowy XSS. 'unsafe-eval' dopuszcza eval(). Wildcard * zezwala na dowolne źródło. Taki CSP daje fałszywe poczucie bezpieczeństwa i dlatego w naszym skanerze oceniamy nie tylko obecność, ale i jakość polityki.

Praktyczne podejście do wdrożenia:

Zacznij od trybu raportującego (Content-Security-Policy-Report-Only) — polityka nie blokuje niczego, ale zgłasza naruszenia. Zbierzesz listę legalnych źródeł bez psucia strony.
Zbuduj politykę opartą na whiteliście domen albo — lepiej — na nonce’ach lub hashach dla skryptów inline, zamiast 'unsafe-inline'.
Ustaw object-src 'none' i base-uri 'self' — to tanie ograniczenia zamykające znane wektory obejścia.
Dopiero po okresie obserwacji przełącz na tryb egzekwujący.

Ochrona przed clickjackingiem: frame-ancestors / X-Frame-Options

Clickjacking polega na osadzeniu Twojej strony w niewidocznej ramce na stronie atakującego i nakłonieniu użytkownika do kliknięcia „w ciemno”. Obrona:

Content-Security-Policy: frame-ancestors 'self'
# lub, dla starszych przeglądarek:
X-Frame-Options: DENY

Nowoczesnym standardem jest dyrektywa frame-ancestors w CSP; X-Frame-Options traktuj jako uzupełnienie dla starszych klientów. Jeśli strona nie ma być nigdzie osadzana, ustaw DENY. Jeśli tylko we własnej domenie — SAMEORIGIN lub frame-ancestors 'self'.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Jeden nagłówek, jedna wartość, zero konfiguracji — a blokuje MIME sniffing, czyli zgadywanie przez przeglądarkę typu treści. Bez nosniff plik przesłany jako obraz może zostać zinterpretowany jako skrypt. Nie ma powodu, by go nie ustawić na każdej odpowiedzi.

Referrer-Policy

Nagłówek Referer (tak, z literówką w oryginalnej specyfikacji) informuje stronę docelową, skąd przyszedł użytkownik — łącznie z pełnym adresem, który może zawierać identyfikatory sesji, tokeny czy ścieżki wewnętrzne. Referrer-Policy ogranicza ten wyciek:

Referrer-Policy: strict-origin-when-cross-origin

Ta wartość wysyła pełny adres tylko w obrębie własnej domeny, a do stron trzecich — jedynie sam origin (bez ścieżki i parametrów). To rozsądny domyślny wybór dla większości serwisów.

Permissions-Policy

Dawniej Feature-Policy. Pozwala wyłączyć dostęp do wrażliwych API przeglądarki (kamera, mikrofon, geolokalizacja, płatności), których Twoja aplikacja nie używa:

Permissions-Policy: camera=(), microphone=(), geolocation=()

To ograniczenie „na wszelki wypadek”: jeśli atakujący wstrzyknie kod, nie sięgnie po API, które i tak nie było potrzebne. Wypisz to, czego faktycznie używasz, a resztę zablokuj.

CORS: Access-Control-Allow-Origin

CORS bywa źle rozumiany — to nie zabezpieczenie strony, lecz mechanizm kontrolowanego rozluźnienia polityki tego samego pochodzenia. Najgroźniejszy błąd to odbijanie dowolnego Origin:

# Bardzo niebezpieczne, jeśli w parze z ciasteczkami sesji:
Access-Control-Allow-Origin: <dowolne odbite źródło>
Access-Control-Allow-Credentials: true

Taka konfiguracja pozwala dowolnej stronie w internecie wykonać uwierzytelnione żądanie do Twojego API w imieniu zalogowanego użytkownika i odczytać odpowiedź. To realny wyciek danych, nie teoria. Zasady:

Nie odbijaj Origin bezrefleksyjnie — utrzymuj listę zaufanych domen.
Access-Control-Allow-Credentials: true łącz wyłącznie z konkretnym, pojedynczym źródłem, nigdy z *.
Dla publicznych, nieuwierzytelnionych zasobów wildcard * bez credentials jest w porządku.

Więcej o typowych błędach w interfejsach programistycznych piszemy w artykule Bezpieczeństwo API według OWASP.

Flagi ciasteczek: Secure, HttpOnly, SameSite

Nagłówki to nie tylko Set-Cookie w drugą stronę. Ciasteczka sesyjne powinny mieć trzy flagi:

Secure — wysyłane tylko po HTTPS.
HttpOnly — niedostępne z poziomu JavaScriptu, co utrudnia kradzież sesji przez XSS.
SameSite=Lax (lub Strict) — ogranicza wysyłanie ciasteczka przy żądaniach z innych witryn, co jest podstawową obroną przed CSRF.

Brak którejkolwiek z tych flag przy ciasteczku sesyjnym to standardowe znalezisko w audycie aplikacji.

Mixed content: HTTPS, które nie jest w pełni HTTPS

Nawet na stronie serwowanej po HTTPS pojedynczy skrypt czy obraz ładowany po http:// (tzw. mixed content) otwiera furtkę do manipulacji treścią i psuje gwarancje szyfrowania. Przeglądarki blokują aktywne treści mieszane, ale warto je wyeliminować u źródła — wszystkie zasoby powinny iść po HTTPS.

Czego nie robić

Nie polegaj wyłącznie na nagłówkach. CSP nie naprawi podatnej aplikacji — jest warstwą ograniczającą skutki, nie zamiennikiem walidacji danych wejściowych. Nagłówki i OWASP Top 10 to komplementarne warstwy.
Nie ustawiaj X-XSS-Protection. Ten nagłówek jest przestarzały i w niektórych przypadkach sam wprowadzał podatności. Nowoczesne przeglądarki go ignorują — zamiast niego stosuj CSP.
Nie kopiuj cudzej polityki CSP w ciemno. Polityka jest ściśle zależna od tego, co ładuje Twoja aplikacja. Skopiowana z internetu albo zablokuje pół strony, albo będzie zbyt liberalna.

Jak zweryfikować konfigurację

Ręczne sprawdzanie każdego nagłówka na każdym poddomenie jest żmudne. Nasz darmowy skaner bezpieczeństwa strony sprawdza komplet nagłówków (HSTS, CSP z oceną jakości, X-Frame-Options, nosniff, Referrer- i Permissions-Policy), konfigurację CORS, mixed content, flagi ciasteczek oraz wygaśnięcie certyfikatu — i zwraca wynik z konkretnymi rekomendacjami. Jak czytać taki raport, tłumaczymy w artykule Jak czytać wynik skanu bezpieczeństwa.

Skaner pasywny pokazuje jednak tylko higienę konfiguracji. Realne podatności w logice aplikacji, obejścia autoryzacji czy łańcuchy błędów wykrywa dopiero manualny test penetracyjny — skontaktuj się z nami, jeśli chcesz sprawdzić aplikację głębiej niż na poziomie nagłówków.

Podsumowanie: minimalny zestaw

Dla typowej aplikacji webowej rozsądny punkt wyjścia to:

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

…plus flagi Secure; HttpOnly; SameSite=Lax na ciasteczkach sesyjnych i restrykcyjny CORS. To fundament, który zamyka najczęstsze, tanie w naprawie luki — resztą powinien zająć się przegląd całej aplikacji.

Najczęstsze pytania (FAQ)

Czy dodanie nagłówków bezpieczeństwa może coś zepsuć? Tak — zwłaszcza CSP potrafi zablokować legalne skrypty i style, jeśli polityka jest zbyt restrykcyjna. Dlatego CSP wdraża się etapami, zaczynając od trybu Report-Only. Pozostałe nagłówki (HSTS, nosniff, Referrer-Policy) są bezpieczne do włączenia od razu, choć przy HSTS z preload należy najpierw upewnić się, że cała domena działa po HTTPS.

Gdzie ustawia się te nagłówki — w aplikacji czy na serwerze? Można w obu miejscach. Najczęściej ustawia się je na poziomie serwera WWW (nginx, Apache), reverse proxy lub CDN — dzięki temu obejmują całą aplikację jednolicie. Nagłówki zależne od kontekstu (np. nonce w CSP) generuje aplikacja.

Czy nagłówki bezpieczeństwa wpływają na SEO? Bezpośrednio nie są czynnikiem rankingowym, ale HTTPS i brak treści mieszanych już tak, a poprawna konfiguracja buduje zaufanie i eliminuje ostrzeżenia przeglądarki, które zniechęcają użytkowników. To pośredni, ale realny wpływ.

Jak często sprawdzać konfigurację nagłówków? Po każdej większej zmianie w aplikacji lub infrastrukturze oraz cyklicznie — konfiguracja lubi „dryfować” przy migracjach i wdrożeniach nowych usług. Szybki skan zajmuje kilka sekund i dobrze nadaje się do regularnej kontroli.