Generator nagłówków bezpieczeństwa Nginx

Generator nagłówków bezpieczeństwa Nginx

Nagłówki bezpieczeństwa Nginx to kilka dyrektyw add_header w bloku server, które chronią użytkowników przed przechwyceniem połączenia, clickjackingiem, XSS i wyciekiem adresów URL. Generator składa je z formularza, sprawdza składnię CSP i Permissions-Policy, ocenia konfigurację w skali 6 podstawowych zabezpieczeń i pozwala pobrać gotowy plik security-headers.conf.

Najważniejsze nagłówki

Przykład: konfiguracja z zestawu „Zalecany”

Tak wygląda wynik ustawień domyślnych po wyłączeniu komentarzy. Generator liczy tu 7 dyrektyw, pokazuje HSTS na 365 dni i ocenia pokrycie na 6 z 6:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'" always;
server_tokens off;

Zestaw „Restrykcyjny” podnosi max-age do 63072000 s (730 dni), ustawia DENY, no-referrer, COOP same-origin i CSP z object-src 'none' oraz frame-ancestors 'none'. „Łagodny” zostawia w CSP 'unsafe-inline' i 'unsafe-eval', więc generator od razu ostrzega, że taka polityka słabo chroni przed XSS.

Uwagi

• always dodaje nagłówek także do odpowiedzi błędów,
• HSTS włączaj dopiero, gdy HTTPS działa poprawnie — jest „lepki” w przeglądarce,
• CSP testuj najpierw w trybie Content-Security-Policy-Report-Only (w generatorze: pole „Tryb Report-Only”),
• nagłówka X-XSS-Protection generator nie dodaje, bo jest przestarzały; ochronę przed XSS daje CSP.

Jak działa generator nagłówków bezpieczeństwa Nginx

Generator zbiera wartości z formularza i zamienia je na gotowy blok dyrektyw add_header. Każda linia to jeden nagłówek: nazwa, wartość w cudzysłowie oraz flaga always, która sprawia, że nagłówek trafia także do odpowiedzi błędów. Na końcu może dojść server_tokens off, a nad każdą dyrektywą opcjonalny komentarz po polsku. Wynik kopiujesz albo pobierasz jako security-headers.conf, zapisujesz np. w /etc/nginx/snippets/ i dołączasz przez include.

Przed zbudowaniem konfiguracji narzędzie sprawdza dane. W CSP wykrywa fragmenty bez nazwy dyrektywy, nieznane nazwy (zwykle literówki), powtórzone dyrektywy, słowa kluczowe bez apostrofów (self zamiast 'self'), brak default-src oraz 'unsafe-inline', 'unsafe-eval' i zbyt szerokie źródła skryptów, jak *, https: czy data:. W Permissions-Policy pilnuje formatu funkcja=(…) z przecinkami. Opcję preload odrzuca, gdy max-age jest krótszy niż 31536000 s albo wyłączono includeSubDomains. Ostrzega też przed znakiem $, który Nginx traktuje jako zmienną.

Najważniejsza zasada mechanizmu siedzi w samym Nginx, nie w generatorze: dyrektywy add_header dziedziczą się z poziomu nadrzędnego tylko wtedy, gdy na niższym poziomie nie zdefiniowano ani jednej takiej dyrektywy. Jeśli w bloku location pojawi się choćby jedno add_header, nagłówki ustawione w server przestają tam obowiązywać. Dlatego wygenerowany zestaw najlepiej trzymać w osobnym pliku i dołączać przez include w każdym bloku, który dodaje własne nagłówki.

Wartość max-age w HSTS liczy się w sekundach i jest odświeżana przy każdym poprawnym żądaniu po HTTPS — im większa liczba, tym dłużej przeglądarka pamięta zakaz łączenia się po HTTP. Wzór jest prosty: max-age podzielone przez 86400 daje liczbę dni. Dla 31536000 sekund to dokładnie 365 dni, dla 63072000 – 730 dni. Ściągę z typowymi wartościami znajdziesz bezpośrednio pod formularzem.

Przykład krok po kroku: od formularza do działającej konfiguracji

1. Wybierasz zestaw „Zalecany”. HSTS dostaje wartość max-age=31536000; includeSubDomains, czyli 31536000 / 86400 = 365 dni, i tyle pokazuje kafelek HSTS.
2. Jeśli HTTPS dopiero uruchamiasz, zmieniasz max-age na 300 (5 minut) albo 604800 (7 dni). Generator doda uwagę, że wartość krótsza niż rok nadaje się na testy, ale jest za krótka dla listy preload.
3. Zaznaczasz tryb Report-Only. Nagłówek zmienia się na Content-Security-Policy-Report-Only, a ocena spada do 5 z 6, bo taka polityka tylko zgłasza naruszenia i niczego nie blokuje.
4. Klikasz „Generuj nagłówki”, pobierasz security-headers.conf do /etc/nginx/snippets/ i dopisujesz w bloku server linię include snippets/security-headers.conf;. Uruchamiasz nginx -t i przeładowujesz usługę, np. systemctl reload nginx.
5. Sprawdzasz realną odpowiedź serwera poleceniem curl -I https://twojadomena.pl. Powinny być widoczne wszystkie wygenerowane nagłówki, a nagłówek Server bez numeru wersji.
6. Po kilku dniach przeglądasz naruszenia CSP w konsoli przeglądarki i dopisujesz brakujące źródła skryptów, stylów i fontów. Gdy naruszeń nie ma, wyłączasz Report-Only i etapami wydłużasz max-age: 30 dni, rok, docelowo 2 lata (63072000 s).

Tabela referencyjna: nagłówek, wartość, co sprawdzić przed włączeniem

Praktyczne wskazówki wdrożenia

• Trzymaj nagłówki w jednym pliku. Zestaw z generatora dołącz przez include w bloku server i powtórz ten sam include w każdym bloku location, który ma własne add_header, bo inaczej nagłówki z server w nim znikną.
• Wdrażaj warstwami. Zacznij od nagłówków, które nie zmieniają działania strony, potem dodaj ograniczenia ramek, a na końcu HSTS i politykę treści — każdy z tych etapów może ujawnić inny problem.
• HSTS wprowadzaj stopniowo: zacznij od krótkiego max-age, np. 604800, czyli 7 dni licząc po 86400 sekund na dobę, i wydłuż go do 31536000 dopiero wtedy, gdy HTTPS działa stabilnie na wszystkich hostach.
• Sprawdzaj odpowiedź, nie tylko konfigurację. Nagłówki mogą zostać nadpisane przez aplikację, reverse proxy lub CDN, dlatego po każdym wdrożeniu zrób curl -I i porównaj wynik z plikiem.

Ograniczenia narzędzia

• Nie zna Twojej infrastruktury. Generator nie sprawdzi, czy przed Nginx stoi proxy lub CDN, który dokłada albo nadpisuje nagłówki, ani czy aplikacja wysyła własne.
• Nie ustali listy dozwolonych źródeł. Sprawdza składnię CSP, ale nie wie, z jakich domen ładujesz skrypty, style czy fonty, więc zbyt wąska polityka zablokuje działające elementy strony.
• Nie obsługuje wartości dynamicznych. Polityka treści oparta na nonce wymaga generowania losowej wartości przy każdym żądaniu po stronie aplikacji, czego statyczna konfiguracja nie zrobi.
• Nie weryfikuje subdomen i certyfikatów. Nie sprawdzi, czy wszystkie hosty objęte includeSubDomains mają poprawny certyfikat i odpowiadają po HTTPS.
• Nie usuwa podatności. Nagłówki ograniczają skutki niektórych ataków, ale nie naprawiają błędów w kodzie, słabego uwierzytelniania ani wycieków danych.