Jak skonfigurować nagłówki bezpieczeństwa HTTP przez .htaccess vs Nginx

Nagłówki bezpieczeństwa HTTP to nagłówki odpowiedzi, które mówią przeglądarkom, aby wymuszały określone zachowania bezpieczeństwa podczas renderowania strony. Konfiguruje się je na serwerze webowym, nie w WordPressie, i nie kosztują wydajności po włączeniu. Witryna WordPress z poprawnymi nagłówkami blokuje clickjacking, downgrade do mieszanej treści, exploity MIME-sniffing i dużą część payloadów cross-site scripting. Konfiguracja to jednorazowa zmiana w pliku .htaccess Apache lub w config serwera Nginx. Poniżej znajduje się siedem nagłówków, które mają znaczenie w 2026 roku, ze snippetami gotowymi do skopiowania dla obu serwerów webowych.

Jakie nagłówki bezpieczeństwa HTTP powinna ustawiać witryna WordPress?

Siedem nagłówków pokrywa realistyczny model zagrożeń dla witryny opartej na treści. W kolejności priorytetu:

• Strict-Transport-Security (HSTS). Wymusza w przeglądarkach używanie HTTPS przez rok (lub dłużej) po pierwszej wizycie, zapobiegając atakom HTTPS-stripping w publicznym WiFi. Obowiązkowy, jeśli twoja witryna ma zalogowanych użytkowników.
• Content-Security-Policy (CSP). Mówi przeglądarce dokładnie, jakie źródła JavaScript, CSS, obrazów i czcionek są dozwolone. Najbardziej wpływowy nagłówek przeciwko XSS, ale także najtrudniejszy do skonfigurowania bez psucia witryny.
• X-Frame-Options lub dyrektywa CSP frame-ancestors. Zapobiega osadzaniu twojej witryny w iframe na innej domenie, blokując ataki clickjacking przeciwko formularzowi logowania.
• X-Content-Type-Options: nosniff. Zatrzymuje przeglądarki od zgadywania typu treści odpowiedzi, zamykając klasę ataków "prześlij fałszywy obraz, który tak naprawdę jest JavaScriptem".
• Referrer-Policy. Kontroluje, ile bieżącego URL jest wysyłane w nagłówku Referer przy klikach wychodzących. Domyślne ustawienia wyciekają query stringi stronom trzecim; strict-origin-when-cross-origin to nowoczesna rekomendacja.
• Permissions-Policy (dawniej Feature-Policy). Wyłącza funkcje przeglądarki, których twoja witryna nie używa (kamera, mikrofon, geolokalizacja), co zmniejsza narażenie, jeśli jakiś skrypt strony trzeciej kiedykolwiek spróbuje do nich uzyskać dostęp.
• Cross-Origin-Opener-Policy. Izoluje twoją witrynę od jakichkolwiek okien popup, które otwiera, łagodząc ataki typu side-channel klasy Spectre. Wymagany do działania SharedArrayBuffer.

Co już nie jest zalecane: X-XSS-Protection (przestarzały, przeglądarki go ignorują), Public-Key-Pins (przestarzały, powodował za dużo blokad) i Expect-CT (przestarzały od 2023).

Apache .htaccess: blok kopiuj-wklej dla nagłówków bezpieczeństwa

Dodaj to na górze .htaccess w katalogu głównym WordPressa, powyżej bloku WordPress (# BEGIN WordPress). Strażnik IfModule zapewnia, że snippet nie crashuje, jeśli mod_headers brakuje.

<IfModule mod_headers.c>
    # HSTS: wymuś HTTPS na 1 rok, włącz subdomeny, gotowy do preload
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    # Zapobieganie clickjackingowi
    Header always set X-Frame-Options "SAMEORIGIN"

    # Blokuj MIME-sniffing
    Header always set X-Content-Type-Options "nosniff"

    # Ogranicz wyciek referrer
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    # Wyłącz nieużywane funkcje przeglądarki
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), interest-cohort=()"

    # Izolacja cross-origin
    Header always set Cross-Origin-Opener-Policy "same-origin"

    # Konserwatywny startowy CSP; zaostrzyć, gdy będzie wiadomo, co witryna ładuje
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https:; style-src 'self' 'unsafe-inline' https:; img-src 'self' data: https:; font-src 'self' data: https:; connect-src 'self' https:; frame-ancestors 'self'; base-uri 'self'; form-action 'self';"
</IfModule>

Słowo kluczowe always jest krytyczne. Bez niego nagłówki są wysyłane tylko w odpowiedziach 2xx i 3xx; z nim strony błędów i przekierowania również niosą nagłówki. Bez always atakujący, który wywołuje błąd 500, widzi nieochronioną odpowiedź.

Moduł mod_headers musi być włączony. Na hostingu współdzielonym zwykle już jest. Na samodzielnie zarządzanym Apache: sudo a2enmod headers && sudo systemctl reload apache2.

Nginx: blok kopiuj-wklej dla nagłówków bezpieczeństwa

Dodaj to wewnątrz bloku server { ... } swojej witryny, zwykle w /etc/nginx/sites-available/twojawitryna.conf:

    # HSTS: wymuś HTTPS na 1 rok, włącz subdomeny, gotowy do preload
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # Zapobieganie clickjackingowi
    add_header X-Frame-Options "SAMEORIGIN" always;

    # Blokuj MIME-sniffing
    add_header X-Content-Type-Options "nosniff" always;

    # Ogranicz wyciek referrer
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Wyłącz nieużywane funkcje przeglądarki
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), interest-cohort=()" always;

    # Izolacja cross-origin
    add_header Cross-Origin-Opener-Policy "same-origin" always;

    # Konserwatywny startowy CSP; zaostrzyć, gdy będzie wiadomo, co witryna ładuje
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https:; style-src 'self' 'unsafe-inline' https:; img-src 'self' data: https:; font-src 'self' data: https:; connect-src 'self' https:; frame-ancestors 'self'; base-uri 'self'; form-action 'self';" always;

Końcowe always w Nginx służy temu samemu celowi co w Apache: sprawia, że nagłówek dotyczy również odpowiedzi błędów. Przeładuj Nginx po zmianie: sudo nginx -t && sudo systemctl reload nginx.

Reguła dwóch pułapek Nginx add_header

Nginx ma osobliwość, która wielokrotnie gryzie ludzi. Dwie reguły do zinternalizowania przed dotknięciem konfiguracji produkcyjnej:

• add_header jest zastępowany, nie scalany. Jeśli ustawisz nagłówki w bloku server i ponownie w bloku location, nagłówki bloku location zastępują nagłówki bloku server dla tej lokalizacji. Nie dodają się do nich. Objaw: nagłówki działają wszędzie z wyjątkiem konkretnej lokalizacji (jak /wp-admin/, gdzie dodałeś niestandardową regułę).
• Zawsze dodawaj flagę always. Bez niej strona 404 lub strona błędu 500 jest serwowana bez twoich nagłówków bezpieczeństwa. Atakujący mogą celowo wywoływać błędy, aby obejść ochronę opartą na nagłówkach.

Apache Header always set jest odpowiednikiem flagi Nginx always i ma ten sam efekt.

Apache vs Nginx: który jest łatwiejszy do konfiguracji?

Praktycznie równoważne dla nagłówków bezpieczeństwa. Oba używają jednej dyrektywy na nagłówek i akceptują identyczne wartości nagłówków. Trzy różnice warte poznania:

• Gdzie żyje konfiguracja. Apache poprzez .htaccess może być edytowany per-katalog przez każdego z dostępem FTP do instalacji WordPress. Konfiguracja Nginx żyje poza document root i zwykle wymaga SSH oraz reloadu. Dla hostingu WordPress współdzielonego, .htaccess jest bardziej praktyczny; dla zarządzanych setupów Nginx, konfiguracja serwera jest bardziej wydajna (Nginx nie odczytuje reguł równoważnych .htaccess przy każdym żądaniu, trzyma poprawną konfigurację nginx w pamięci).
• Nadpisania per-lokalizacja. Apache .htaccess automatycznie dziedziczy ustawienia katalogu nadrzędnego. Bloki location Nginx wymagają jawnego ponownego deklarowania, jeśli dostosujesz jeden (z powodu pułapki scalania powyżej).
• Rzeczywistość hostingu. Większość współdzielonych hostingów WordPress (Hostinger, IONOS, GoDaddy, tradycyjne hosty cPanel) to Apache. Większość zarządzanych hostingów WordPress (Kinsta, WP Engine, Raidboxes, SiteGround, Cloudways) to Nginx. Procentowy podział przesunął się z większości-Apache do mniej więcej 50/50 w ciągu ostatnich pięciu lat.

Czy powinienem dodawać nagłówki bezpieczeństwa w WordPressie zamiast na serwerze webowym?

Możesz, ale poziom serwera webowego jest lepszy. Istnieją trzy opcje po stronie WordPress:

• Wtyczka bezpieczeństwa (Wordfence, iThemes Security, itp.). Ma funkcję "nagłówki bezpieczeństwa", która dodaje te same nagłówki po stronie PHP. Działa, ale dodaje kilka milisekund na żądanie. Przydatne, jeśli nie masz dostępu do serwera webowego.
• Niestandardowy kod wtyczki lub motywu. Mała mu-plugin może wywołać header() w PHP, aby emitować każdy nagłówek. Taki sam narzut, takie same zastrzeżenia.
• Konfiguracja serwera webowego (zalecane). Zerowy narzut PHP, dotyczy każdej odpowiedzi włącznie z błędami 404 i plikami statycznymi, przetrwa crashe WordPressa.

Argument za poziomem serwera webowego: nagłówki dodane w PHP nie chronią odpowiedzi, które omijają PHP. Jeśli atakujący osiąga plik statyczny bezpośrednio (zapomniany backup .phps, katalog uploadów z plikami HTML), nagłówki ustawione przez PHP nie są stosowane. Serwer webowy widzi każde żądanie i jest właściwą warstwą.

Jak dostroić Content-Security-Policy bez psucia mojej witryny?

CSP to najbardziej wpływowy nagłówek bezpieczeństwa, a także najbardziej prawdopodobny do popsucia rzeczy. Witryna WordPress domyślnie ładuje skrypty i style z dziesiątek źródeł: jQuery z /wp-includes, zasoby motywu, zasoby wtyczek, Google Fonts (jeśli nie są samodzielnie hostowane), analityka, osadzone YouTube itd. Surowa CSP, która nie whitelistuje ich jawnie, zablokuje je, a witryna będzie wyglądać na zepsutą w subtelne sposoby (logowanie nie działa, galeria nie działa, analityka się zatrzymuje).

Dwufazowy wzorzec wdrożenia, który działa:

1. Zacznij w trybie report-only. Użyj Content-Security-Policy-Report-Only zamiast Content-Security-Policy. Przeglądarka niczego nie blokuje; po prostu loguje naruszenia do konsoli deweloperskiej. Przeglądaj witrynę przez kilka dni, monitoruj, co byłoby zablokowane, i dodaj uzasadnione źródła do swojej polityki.
2. Przełącz na tryb enforcing. Gdy tryb report-only pokazuje zero naruszeń przy normalnej nawigacji, zmień nazwę nagłówka z powrotem na Content-Security-Policy. Teraz naruszenia są blokowane.

Jedna częsta pułapka: WordPress i wiele wtyczek używa inline handlerów zdarzeń JavaScript (onclick="") i inline bloków <script>. Surowa CSP wymaga albo 'unsafe-inline' (pokonuje większość ochrony) albo nonces dla każdego inline skryptu (znaczące zmiany kodu). Pragmatyczny środek w 2026: zachowaj 'unsafe-inline' na razie, ale zablokuj inne dyrektywy. Przyszłe wersje WordPressa zmierzają w kierunku inline skryptów przyjaznych dla nonces.

Jak sprawdzić, że moje nagłówki bezpieczeństwa działają?

Cztery metody, od najszybszej do najbardziej autorytatywnej:

1. Raport InspectWP. Sekcja Bezpieczeństwa wymienia każdy nagłówek, który twoja witryna ustawia, jego wartość, i oznacza brakujące lub źle skonfigurowane. Jeden ekran.
2. curl z linii komend. curl -I https://twojawitryna.com drukuje nagłówki odpowiedzi. Poszukaj siedmiu nagłówków powyżej; zweryfikuj ich wartości.
3. securityheaders.com. Bezpłatny publiczny skaner, który ocenia twoją witrynę (A+ do F) i wyjaśnia, które nagłówki brakują lub są słabe. Standard branżowy dla audytów nagłówków.
4. DevTools przeglądarki. Otwórz DevTools (F12), kartę Network, kliknij żądanie dokumentu, spójrz na sekcję Response Headers. Przydatne do oglądania naruszeń CSP na żywo w karcie Console.

Częste błędy i pułapki

• Dodawanie HSTS bez potwierdzenia, że HTTPS działa w całej witrynie. HSTS wymusza w przeglądarkach używanie HTTPS przez rok. Jeśli twoja witryna ma zepsuty certyfikat lub podstronę, która działa tylko przez HTTP, użytkownicy zostają zablokowani. Przetestuj HTTPS dokładnie przed włączeniem HSTS. Zacznij od krótkiego max-age (jak 300 sekund) i zwiększaj do roku.
• Ustawianie X-Frame-Options I CSP frame-ancestors. Oba działają, ale frame-ancestors to nowoczesny odpowiednik. Ustawianie obu jest redundantne, ale nieszkodliwe; nowoczesne przeglądarki preferują frame-ancestors.
• Zapomnienie includeSubDomains w HSTS. Jeśli twoja główna witryna to HTTPS, ale subdomena nadal serwuje HTTP, atakujący mogą pivotować przez subdomenę. includeSubDomains wymusza HTTPS wszędzie pod twoją domeną. Zweryfikuj, że wszystkie subdomeny są HTTPS przed dodaniem tego.
• Kopiowanie CSP z ogólnego tutoriala. Każda witryna WordPress ładuje inne zasoby stron trzecich. Ogólna CSP zepsuje twoją witrynę. Użyj najpierw trybu report-only.
• Mieszanie nagłówków CDN i origin. Jeśli masz Cloudflare z przodu, możesz ustawić nagłówki w Cloudflare (Page Rules lub Transform Rules) lub w origin. Ustawienie obu z różnymi wartościami powoduje zamieszanie przy debugowaniu. Wybierz jedno miejsce i udokumentuj.
• Zapomnienie przeładowania po edycji. Zmiany Nginx nic nie robią aż do systemctl reload nginx. Zmiany .htaccess Apache są natychmiastowe; zmiany głównej konfiguracji Apache wymagają reloadu.

A co z HTTP/3 i nowoczesną historią nagłówków?

HTTP/3 nie zmienia niczego co do tego, jakie nagłówki ustawiać; semantyka nagłówków jest identyczna w HTTP/1.1, HTTP/2 i HTTP/3. Jeden nagłówek, który staje się istotny w HTTP/3, to Alt-Svc, który ogłasza dostępność HTTP/3 klientom, którzy przyszli przez HTTP/2. Większość serwerów webowych dodaje to automatycznie.

Krajobraz przeglądarek również stopniowo przesuwa się w kierunku egzekwowania nowoczesnych domyślnych ustawień nawet gdy nagłówki brakują. Chrome i Firefox domyślnie używają teraz strict-origin-when-cross-origin dla Referrer-Policy, jeśli nie wysłano żadnego nagłówka, i coraz częściej zakładają HTTPS dla każdej witryny, która kiedykolwiek była serwowana przez HTTPS. Jawne ustawianie nagłówków jest nadal zalecane, ponieważ domyślne ustawienia różnią się w zależności od wersji przeglądarki i ponieważ klienty HTTP nienależące do przeglądarek (curl, skrypty, narzędzia monitoringu) nie implementują tych domyślnych ustawień.

Co sprawdza InspectWP

Sekcja Bezpieczeństwa każdego raportu InspectWP inspekcjonuje nagłówki odpowiedzi twojego głównego dokumentu i raportuje, które ze standardowych nagłówków bezpieczeństwa są obecne, jakie są ich wartości, i które brakują lub są ustawione na niezalecane wartości. Brakujące HSTS na witrynie HTTPS jest oznaczane jako ostrzeżenie; brakujące X-Content-Type-Options jest oznaczane jako informacyjne; CSP ustawiona na default-src * (efektywnie brak polityki) jest oznaczana jako błędna konfiguracja. Raport również zauważa, kiedy nagłówki są ustawione na poziomie CDN versus na poziomie origin, ponieważ wpływa to na to, co musiałbyś zmienić, aby je zaktualizować. Zalecany stan to wszystkie siedem nagłówków obecnych z rozsądnymi wartościami, a CSP albo w trybie report-only podczas dostrajania, albo w trybie enforcing po dostrojeniu.