Jak skonfigurować Content-Security-Policy w WordPressie

Content-Security-Policy (CSP) to jeden z najpotężniejszych dostępnych nagłówków bezpieczeństwa, ale też jeden z najtrudniejszych do poprawnego skonfigurowania w WordPressie. Powód jest prosty: rdzeń WordPressa, motywy i wtyczki chętnie używają inline scriptów i stylów. Ścisły CSP domyślnie blokuje je, co oznacza, że Twoja strona może się zepsuć w nieoczekiwany sposób, jeśli nie zaplanujesz starannie. Ten przewodnik prowadzi przez cały proces, od zrozumienia, co robi CSP, po wdrożenie polityki gotowej do produkcji.

Dlaczego CSP jest szczególnie trudny w WordPressie

Większość witryn WordPress mocno polega na wzorcach, które CSP właśnie ma ograniczać. Oto najczęstsze problemy, z którymi się spotkasz:

• Inline scripty: wiele wtyczek wstrzykuje JavaScript bezpośrednio w HTML przez tagi <script> bez atrybutu src. Buildery stron jak Elementor, WPBakery i Divi robią to często.
• Inline style: WordPress Customizer, bloki Gutenberg i większość motywów dodają atrybuty style lub bloki <style> do strony. Ścisły CSP bez 'unsafe-inline' dla stylów psuje wizualny wygląd Twojej strony.
• Użycie eval(): niektóre wtyczki używają funkcji JavaScript eval() lub podobnych konstruktów, które wymagają dyrektywy 'unsafe-eval'.
• Zewnętrzne zasoby: Google Analytics, Google Fonts, reCAPTCHA, osadzone filmy YouTube, widżety mediów społecznościowych. Dla każdego potrzebny jest osobny wpis CSP.

Z tego wszystkiego powodu nigdy nie powinieneś kopiować i wklejać CSP z innej witryny do swojej konfiguracji WordPress. Każda witryna WordPress ma unikalną kombinację wtyczek i motywów, więc każdy CSP musi być dostosowany.

Zacznij w trybie report-only, by odkryć, co by się zepsuło

Najbezpieczniejszy sposób na rozpoczęcie to nagłówek Content-Security-Policy-Report-Only. Ten nagłówek zachowuje się dokładnie jak CSP, z wyjątkiem tego, że nic faktycznie nie blokuje. Zamiast tego naruszenia są logowane w konsoli przeglądarki, więc widzisz, co Twoja polityka zatrzymałaby. Nic na Twojej stronie się nie psuje, ale masz pełną widoczność.

Dodaj to do pliku .htaccess (Apache):

<IfModule mod_headers.c>
    Header set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self';"
</IfModule>

Lub dla Nginx:

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self';" always;

Pozwól temu działać co najmniej kilka dni i przeglądaj wszystkie ważne strony swojej witryny (strona główna, artykuły blogowe, formularz kontaktowy, checkout WooCommerce, jeśli ma zastosowanie). Każda strona może ładować inne wtyczki i zasoby.

Jak znaleźć naruszenia CSP w konsoli przeglądarki

Po włączeniu trybu Report-Only otwórz swoją stronę w Chrome lub Firefox i naciśnij F12, by otworzyć DevTools. Przejdź do zakładki Console. Naruszenia CSP pojawiają się jako wiadomości ostrzegawcze wyglądające tak:

[Report Only] Refused to load the script 'https://www.googletagmanager.com/gtag/js' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline'".

Każda wiadomość o naruszeniu mówi dokładnie, co zostało zablokowane i która dyrektywa to spowodowała. Zbierz wszystkie te wiadomości i użyj ich do zbudowania swojej listy zezwoleń. Odwiedź każdą ważną stronę na swojej witrynie, w tym strony z formularzami, sliderami, mapami i strony ładujące unikalne wtyczki.

Najważniejsze dyrektywy CSP dla WordPressa

Oto dyrektywy, które prawdopodobnie musisz skonfigurować:

• default-src: fallback dla wszystkich typów zasobów, które nie są wyraźnie wymienione. Ustaw na 'self' jako podstawę.
• script-src: kontroluje, skąd można ładować JavaScript. Na WordPressie prawie na pewno potrzebujesz 'unsafe-inline'. Jeśli wtyczka używa eval(), potrzebujesz też 'unsafe-eval'.
• style-src: kontroluje, skąd można ładować CSS. WordPress prawie zawsze wymaga tu 'unsafe-inline'.
• img-src: kontroluje źródła obrazów. Użyj 'self' data: https:, by zezwolić na własne obrazy, URI data (używane przez wiele wtyczek) i każdy obraz przez HTTPS.
• font-src: kontroluje ładowanie fontów. Jeśli używasz Google Fonts, dodaj https://fonts.gstatic.com.
• connect-src: kontroluje, dokąd JavaScript może wykonywać żądania sieciowe (AJAX, fetch, WebSocket). Obszar administracyjny WordPress mocno tego używa dla REST API i Heartbeat API.
• frame-src: kontroluje, jakie domeny mogą być ładowane w iframe'ach. Potrzebne dla osadzeń YouTube (https://www.youtube.com), Google Maps (https://www.google.com) i reCAPTCHA (https://www.google.com).
• media-src: kontroluje źródła audio i wideo. Zwykle 'self' wystarcza, chyba że osadzasz zewnętrzne media.
• object-src: kontroluje wtyczki takie jak Flash. Ustaw na 'none', ponieważ Flash jest martwy, a ta dyrektywa głównie odpiera starsze wektory ataków.

Budowanie polityki krok po kroku

Zacznij od restrykcyjnej bazy i dodawaj wyjątki w miarę odkrywania naruszeń:

1. Zacznij od minimalnej polityki: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self';
2. Dodaj unsafe-inline dla scriptów i stylów: jest to prawie zawsze potrzebne w WordPressie. script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';
3. Dodaj URI data dla obrazów i fontów: wiele wtyczek używa obrazów zakodowanych w base64. img-src 'self' data: https:; font-src 'self' data:;
4. Whitelistuj swój CDN: jeśli używasz CDN, takiego jak Cloudflare lub BunnyCDN, dodaj domenę do script-src, style-src, img-src i font-src.
5. Dodawaj zewnętrzne usługi pojedynczo: dla każdego naruszenia CSP w konsoli dodaj konkretną domenę do odpowiedniej dyrektywy.

Typowe wpisy whitelist dla witryn WordPress

Oto przegląd domen, których możesz potrzebować dla popularnych integracji WordPress:

• Google Fonts: style-src https://fonts.googleapis.com i font-src https://fonts.gstatic.com
• Google Analytics / GA4: script-src https://www.googletagmanager.com https://www.google-analytics.com i connect-src https://www.google-analytics.com https://analytics.google.com
• Google Maps: script-src https://maps.googleapis.com i frame-src https://www.google.com
• Osadzenia YouTube: frame-src https://www.youtube.com https://www.youtube-nocookie.com
• reCAPTCHA: script-src https://www.google.com https://www.gstatic.com i frame-src https://www.google.com
• Gravatar: img-src https://secure.gravatar.com https://www.gravatar.com
• WordPress.org: img-src https://s.w.org https://ps.w.org (dla ikon wtyczek/motywów w obszarze admina)

Kompletny przykład CSP dla WordPressa

Oto realistyczny CSP dla witryny WordPress używającej Google Analytics, Google Fonts, osadzeń YouTube i Gravatar. Dostosuj do swoich konkretnych potrzeb:

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https: https://secure.gravatar.com; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self' https://www.google-analytics.com https://analytics.google.com; frame-src https://www.youtube.com https://www.youtube-nocookie.com; object-src 'none'; base-uri 'self'; form-action 'self';"
</IfModule>

Wtyczki WordPress do zarządzania CSP

Jeśli edycja plików konfiguracyjnych serwera wydaje się zniechęcająca, te wtyczki mogą pomóc:

• HTTP Headers: bezpłatna wtyczka, która pozwala definiować wszystkie nagłówki bezpieczeństwa z obszaru administracyjnego WordPress. Wspiera CSP z przyjaznym interfejsem, gdzie możesz dodawać źródła per dyrektywa.
• Really Simple SSL Pro: zawiera moduł Content-Security-Policy z logiem naruszeń i jednoklikowymi rozwiązaniami dla typowych problemów.
• Wtyczka CSP od Jeremykendall: lekka opcja skupiająca się wyłącznie na zarządzaniu CSP.

Pamiętaj, że nagłówki CSP oparte na wtyczkach są wysyłane tylko dla stron przetwarzanych przez WordPress. Statyczne zasoby dostarczane bezpośrednio przez Twój serwer WWW nie noszą nagłówka. Dla pełnej ochrony konfiguracja na poziomie serwera ma pierwszeństwo.

Przejście z Report-Only na tryb wymuszania

Jeśli działałeś w trybie Report-Only przez co najmniej tydzień i rozwiązałeś wszystkie naruszenia, jesteś gotowy na przełączenie. Po prostu zmień nazwę nagłówka z Content-Security-Policy-Report-Only na Content-Security-Policy. Trzymaj otwartą konsolę przeglądarki przez pierwsze kilka godzin i monitoruj naruszenia, które mogłeś przegapić. Jeśli coś się zepsuje, zawsze możesz wrócić do Report-Only, gdy to rozwiążesz.

Zweryfikuj swój CSP z InspectWP

Po wdrożeniu Content-Security-Policy wykonaj nowy skan InspectWP. Sekcja nagłówków bezpieczeństwa w Twoim raporcie pokazuje, czy nagłówek CSP jest obecny i czy jest w trybie Report-Only czy wymuszania. Użyj tego jako szybkiej kontroli po każdej zmianie, by potwierdzić, że Twoja polityka jest nadal poprawnie wysyłana.