Strict CSP – jak bezpiecznie włączyć Content Security Policy w WordPress

Czym jest Strict CSP

Strict CSP to niewielka wtyczka bezpieczeństwa, która wymusza ścisłą politykę Content Security Policy na froncie i ekranie logowania WordPress. Jej celem jest ograniczenie ryzyka XSS poprzez kontrolę tego, skąd przeglądarka może wczytywać i uruchamiać zasoby. W praktyce Strict CSP dodaje nagłówki i atrybuty nonce tak, aby skrypty ładowane zgodnie z API WordPress działały, a wstrzykiwane lub niepoprawnie dodane skrypty były blokowane. Aktualnie polityka nie obejmuje panelu administracyjnego, co wynika z ograniczeń po stronie Core i aktywnych prac nad tym obszarem.

Jak działa – mechanizm CSP we wtyczce

Wtyczka egzekwuje tzw. strict CSP na dwóch obszarach: stronie publicznej i formularzu logowania. Dodaje atrybuty nonce do skryptów generowanych przez WordPress i zapewnia, że osadzenia zewnętrzne, takie jak tweety, również otrzymają odpowiedni nonce. Dzięki temu możliwe jest zablokowanie wykonywania nieautoryzowanych skryptów, w tym inline oraz tych dodanych atrybutami zdarzeń typu onclick czy onload. W konsoli przeglądarki użytkownik zobaczy czytelny komunikat o odmowie wykonania skryptu naruszającego politykę.

Wymagania, zgodność i ograniczenia

Strict CSP działa z WordPress 6.4 i nowszym, został przetestowany do 6.9 i wymaga PHP co najmniej 7.2. Z pełną premedytacją wyłączono działanie w Edytorze Witryny i w panelu WP-Admin, ponieważ tam nadal istnieją miejsca, w których Core lub rozszerzenia opierają się na inline script i konstrukcji znaczników poza standardowym API. To celowy kompromis – w pierwszej kolejności chroniony jest frontend i logowanie, czyli obszary bezpośrednio narażone na XSS wobec użytkowników końcowych.

Instalacja i pierwsza konfiguracja

Instalacja przebiega jak zwykle: dodaj wtyczkę z katalogu i aktywuj. Po włączeniu zalecane jest wylogowanie i ponowne logowanie z zaznaczoną opcją zapamiętania, aby poprawnie zainicjować przepływ nonce. Nie ma tu rozbudowanych ustawień – wtyczka działa po aktywacji i opiera się na standardowych mechanizmach WordPress. Jeżeli wolisz instalację ręczną, dostępna jest paczka ZIP oraz repozytorium projektu.

Wpływ na motywy i wtyczki – jak dostosować kod

Kluczowa zmiana mentalna: przestajemy ręcznie drukować znaczniki script i przestajemy polegać na atrybutach zdarzeń w HTML. Strict CSP wymaga, aby wszystkie skrypty trafiały na stronę przez oficjalne API – wp_enqueue_script, wp_add_inline_script, wp_localize_script, wp_print_script_tag, wp_print_inline_script_tag lub wp_enqueue_script_module. To pozwala WordPress dodać nonce i spełnić warunki polityki. Jeżeli motyw lub wtyczka wciąż echo-uje surowe tagi script albo używa onclick w HTML, przeglądarka je zablokuje. W takim przypadku poprawiamy kod, przenosząc logikę do plików JS lub do inline script dodawanego funkcją WordPress, zamiast w HTML.

Część starszych motywów – łącznie z niektórymi motywami domyślnymi – bywa podatna na opisane antywzorce. Przykładowy fix to zamiana echo '<script>...</script>' na wp_print_inline_script_tag('...').

Najczęstsze problemy i diagnostyka

• Po aktywacji przestaje działać jakaś interakcja – sprawdź konsolę przeglądarki. Zwykle winne są inline script bez nonce lub atrybuty zdarzeń.
• Osadzenia zewnętrzne – upewnij się, że trafiają na stronę przez mechanizmy WordPress i otrzymują nonce.
• Wtyczki legacy – zidentyfikuj miejsca, w których drukują tagi script, i przenieś je na API enqueuowania.

Naprawa polega na przejściu na API WordPress i na eliminacji atrybutów zdarzeń w HTML. W rzadkich przypadkach konieczna jest aktualizacja sposobu integracji z usługą zewnętrzną.

Jak Strict CSP ma się do ogólnych porad dot. CSP

Wprowadzenie CSP w WordPress bywa trudne tam, gdzie powszechne są inline script i style. Dopuszczenie unsafe-inline ułatwia start, ale znacząco osłabia ochronę. Ścisła polityka oparta o nonce i hashe jest bezpieczniejsza, lecz wymusza porządek w kodzie i zgodność z API. Strict CSP pomaga zbliżyć się do tego stanu bez ręcznej konfiguracji nagłówków i wyjątków, bo integruje się z kolejką skryptów WordPress.

Kiedy warto wdrożyć i dla kogo

• Serwisy, które chcą realnie zredukować ryzyko XSS na froncie i przy logowaniu.
• Zespoły mające kontrolę nad motywem i kluczowymi wtyczkami – gotowe do drobnych refaktoryzacji pod CSP.
• Witryny podlegające audytom bezpieczeństwa, gdzie wymagany jest ścisły CSP i konsekwentne enqueuowanie zasobów.

W projektach legacy zacznij od sekcji publicznych o największym ruchu, testuj i sukcesywnie eliminuj inline script oraz atrybuty zdarzeń.

Procedura testowa po wdrożeniu

1. Uruchom wtyczkę na środowisku testowym.
2. Przejdź krytyczne ścieżki użytkownika i obserwuj konsolę przeglądarki.
3. Mapuj błędy CSP do miejsc w kodzie i przenoś logikę do API enqueuowania.
4. Zweryfikuj osadzenia zewnętrzne i wprowadź ewentualne poprawki.
5. Sprawdź wskaźniki wydajności – poprawnie ustawione CSP nie powinno pogarszać CWV.

Co z panelem administracyjnym i Site Editorem

Na dziś wtyczka nie stosuje CSP w panelu administracyjnym i w Edytorze Witryny. To świadoma decyzja – te obszary korzystają z innych ścieżek ładowania i licznych inline script. Ochronę frontu i logowania możesz wzmocnić już teraz, a kwestie zaplecza będą ewoluować wraz z rozwojem WordPress.

Dobre praktyki przy CSP w WordPress

• Zawsze dodawaj JS przez API WordPress – nigdy przez ręczne tagi script.
• Unikaj atrybutów onclick, onsubmit i podobnych – używaj addEventListener.
• Inline script traktuj jako wyjątek i dodawaj przez wp_add_inline_script lub wp_print_inline_script_tag, aby otrzymały nonce.
• Przeglądaj motyw i wtyczki pod kątem twardo wstawionych skryptów.
• Testuj integracje zewnętrzne i osadzenia – sprawdź kompatybilność z nonce.
• Edukuj zespół – CSP to polityka, która wymusza dobre nawyki, a nie „magiczny firewall”.