Najważniejsze wnioski
- CSP jest dodatkową warstwą ochrony przeglądarki. Nie zastępuje walidacji danych, bezpiecznego kodowania, aktualizacji komponentów ani testów bezpieczeństwa.
- Najbezpieczniejszy proces wdrożenia zaczyna się od inwentaryzacji zasobów i nagłówka Content-Security-Policy-Report-Only, a nie od blokowania wszystkiego na produkcji.
- W nowoczesnych aplikacjach warto dążyć do strict CSP opartej na nonce’ach lub hashach. Sama długa lista dozwolonych domen zwykle daje słabszą kontrolę.
- Dla e-commerce trzeba osobno przetestować koszyk, logowanie, formularze, płatności, CAPTCHA, analitykę, iframe’y oraz zewnętrzne funkcje wspierające dostępność.
- CSP może zablokować ładowanie widgetu, jeśli jego źródło nie zostało dopuszczone w polityce. Adresy źródeł należy potwierdzić w aktualnej instrukcji dostawcy, a nie wpisywać przykładowych domen do produkcji.
Dla zarządzającego
CSP zmniejsza ryzyko techniczne, ale jest projektem wymagającym właściciela, testów i kontroli zewnętrznych dostawców. Najrozsądniej wdrażać ją etapami, zaczynając od raportowania oraz najważniejszych ścieżek biznesowych.
Dla sprzedaży
CSP nie jest funkcją sprzedażową widoczną dla klienta, lecz może wpływać na działanie checkoutu, czatu, analityki i widgetów. Zespół sprzedaży powinien zgłaszać zespołowi technicznemu każdy nowy skrypt zewnętrzny przed jego uruchomieniem.
Content Security Policy, czyli CSP, warto wdrożyć wtedy, gdy chcesz ograniczyć to, jakie zasoby przeglądarka może uruchamiać na stronie. Najbezpieczniejsza droga nie polega na skopiowaniu gotowego nagłówka z internetu. Zacznij od rozpoznania skryptów i usług zewnętrznych, uruchom tryb raportowania, przetestuj kluczowe ścieżki użytkownika, a dopiero potem włącz blokowanie.
W sklepie internetowym CSP dotyka jednocześnie bezpieczeństwa, marketingu, płatności i dostępności cyfrowej. Może zatrzymać niepożądany skrypt, ale źle skonfigurowana zablokuje też bramkę płatniczą, CAPTCHA, narzędzie analityczne albo funkcje wspierające dostępność. Ten artykuł ma charakter techniczno-informacyjny i opisuje ogólny proces. Konkretna konfiguracja zależy od architektury strony, usług zewnętrznych i sposobu publikacji kodu.
Najważniejsze wnioski
- CSP dostarcza serwer w nagłówku HTTP; przeglądarka porównuje żądane zasoby z dozwolonymi źródłami.
- Nie należy traktować CSP jako zamiennika bezpiecznego programowania i napraw podatności XSS w kodzie.
- Najpierw użyj
Content-Security-Policy-Report-Only, ponieważ ten tryb raportuje naruszenia, ale ich nie blokuje. - W aplikacjach dynamicznych preferowanym kierunkiem jest strict CSP z nonce’ami; dla niezmiennych fragmentów kodu inline przydatne mogą być hashe.
- Po każdej zmianie polityki sprawdź realne zadania użytkownika: wejście na produkt, dodanie do koszyka, płatność, wypełnienie formularza i obsługę strony klawiaturą.
Czym jest Content Security Policy?
CSP to mechanizm bezpieczeństwa przeglądarki definiowany najczęściej nagłówkiem Content-Security-Policy. Polityka mówi między innymi, z jakich źródeł mogą pochodzić JavaScript, style CSS, obrazy, fonty, iframe’y i połączenia sieciowe wykonywane przez aplikację.
Przykładowa, prosta polityka może wyglądać tak:
Content-Security-Policy:
default-src 'self';
img-src 'self' https://images.example.com;'self' oznacza własny origin strony. Dyrektywa default-src określa domyślne źródło dla wielu typów zasobów, a bardziej szczegółowa dyrektywa, tutaj img-src, zastępuje ją dla obrazów.
Dobra CSP nie polega na tym, że „nic się nie ładuje”. Jej celem jest to, aby ładowały się tylko zasoby świadomie dopuszczone i rzeczywiście potrzebne użytkownikowi.
Specyfikacja W3C opisuje CSP jako ochronę warstwową, czyli defense in depth. Nie usuwa ona konieczności walidacji danych wejściowych, kodowania danych wyjściowych, sanitizacji HTML, aktualizowania bibliotek i przeglądu kodu. Więcej o tym, jak bezpiecznie budować fundament strony, znajdziesz w artykule HTML: praktyczny poradnik wdrożenia i pytań.
Jakie problemy CSP rozwiązuje, a jakich nie?
| Obszar | W czym CSP pomaga | Czego CSP nie zastępuje |
|---|---|---|
| Skrypty JavaScript | Może ograniczać wykonywanie skryptów spoza dozwolonych źródeł. | Usuwania podatności XSS, walidacji i bezpiecznego renderowania danych. |
| Osadzanie w ramkach | frame-ancestors może określić, kto może osadzić stronę w iframe. | Pełnej strategii ochrony kont i sesji użytkownika. |
| Zasoby HTTP | upgrade-insecure-requests wspiera przejście żądań na HTTPS. | Poprawnej konfiguracji TLS i eliminacji wszystkich problemów mixed content. |
| Dostępność | Pozwala kontrolować, czy zatwierdzone skrypty wspierające dostępność są ładowane. | Audytu WCAG, testów z użytkownikami ani napraw źródłowych w kodzie i treści. |
W praktyce CSP i dostępność spotykają się przy wdrażaniu usług zewnętrznych. Jeśli polityka blokuje skrypt widgetu, użytkownik nie zobaczy jego panelu ani funkcji takich jak zwiększenie tekstu, kontrast czy czytanie treści. Jednocześnie sam widget nie rozwiązuje problemów w strukturze strony. Granicę między pomocą doraźną a trwałą poprawą wyjaśnia artykuł Widget WCAG: co pomaga, a czego nie naprawi.
Jak działa WCAGbot Accessibility Path przy zmianie CSP?
Wdrożenie CSP bez ryzyka blokady sprzedaży
WCAGbot Accessibility Path porządkuje wdrożenie wtedy, gdy do istniejącej strony dodajesz funkcje wspierające dostępność, a równocześnie kontrolujesz politykę bezpieczeństwa treści.
- Rozpoznaj: ustal, czy strona ma już nagłówek CSP oraz gdzie jest zarządzany: serwer, CDN, reverse proxy, aplikacja lub hosting.
- Potwierdź źródła: sprawdź w aktualnej instrukcji WCAGbot, z jakich dokładnie adresów ładowane są wymagane zasoby. Nie wpisuj do polityki domeny z przykładu znalezionego w artykule lub na forum.
- Dodaj w trybie raportowania: dopuszczaj wyłącznie potwierdzone źródła w odpowiednich dyrektywach, np.
script-src,style-srclubconnect-src, jeśli jest to wymagane przez rzeczywistą integrację. - Przetestuj: otwórz panel na komputerze i telefonie, zwiększ tekst, sprawdź kontrast oraz nawigację klawiaturą.
- Utrwal: po analizie raportów opublikuj egzekwowaną CSP i wróć do testów po każdej zmianie dostawcy, motywu lub skryptów marketingowych.
Doświadczeniowe CTA: na stronie testowej otwórz panel WCAGbot, zwiększ tekst i włącz wybrany tryb kontrastu. Następnie przejdź do konsoli przeglądarki i sprawdź, czy CSP nie generuje komunikatu o zablokowanym zasobie.
Od czego zacząć wdrożenie CSP?
1. Zrób inwentaryzację zasobów i zależności
Nie buduj polityki na podstawie listy technologii używanych „zwykle”. Zbierz rzeczywiste żądania z najważniejszych widoków strony. Uwzględnij pliki JavaScript i CSS, fonty, obrazy, iframe’y, WebSockety, endpointy fetch, narzędzia analityczne, czat, mapy, CAPTCHA, system płatności i mechanizmy obsługi zgód.
W e-commerce koniecznie przejdź ścieżkę produktu, koszyka i checkoutu. Dostępność tych miejsc ma znaczenie zarówno dla użytkownika, jak i procesu sprzedaży. Przygotowanie testów koszyka i płatności omawia artykuł WCAG dla e-commerce: jak ułatwić zakupy online.
2. Ustaw politykę w trybie Report-Only
Na początku użyj osobnego nagłówka:
Content-Security-Policy-Report-Only:
default-src 'self';
script-src 'self';
object-src 'none';
base-uri 'none';Tryb Report-Only sygnalizuje naruszenia, lecz nie zatrzymuje zasobów. Jest właściwy do rozpoznawania zależności, ale nie zapewnia ochrony wynikającej z egzekwowanej polityki. Nie należy pozostawiać go jako jedynego działania końcowego.
3. Analizuj przyczynę, nie tylko adres z raportu
Każde naruszenie odpowiedz sobie na pytanie: czy zasób jest potrzebny, kto jest jego właścicielem, na jakiej stronie jest wykorzystywany i czy można go zastąpić rozwiązaniem własnym lub bezpieczniejszym? Nie rozszerzaj polityki automatycznie o każdą domenę z raportu.
Grupuj naruszenia według dyrektywy, źródła, ścieżki aplikacji, środowiska i wersji wdrożenia. Osobno obserwuj stronę główną, konto klienta, checkout oraz panel administracyjny.
4. Włącz blokowanie etapami
Po sprawdzeniu krytycznych funkcji zmień nagłówek na Content-Security-Policy. W większym serwisie zacznij od wydzielonego obszaru, np. panelu administracyjnego lub strony logowania. Ustal też procedurę na wypadek pilnego wycofania polityki, jeśli ujawniony zostanie błąd na produkcji.
Dlaczego strict CSP jest lepsza od szerokiej allowlisty?
Polityka oparta wyłącznie na liście domen może stawać się coraz szersza wraz z kolejnymi usługami. Przykład script-src https: formalnie dopuszcza skrypty przez HTTPS, ale nie wskazuje, którym konkretnie dostawcom strona ufa. Równie ryzykowne bywa connect-src *, które praktycznie rezygnuje z kontroli kierunków połączeń.
MDN opisuje strict CSP jako podejście oparte na nonce’ach lub hashach. Nonce to nieprzewidywalna wartość generowana dla odpowiedzi HTML i podawana jednocześnie w nagłówku oraz przy dozwolonym skrypcie:
Allowlista domen a strict CSP
Content-Security-Policy:
script-src 'nonce-LOSOWA_WARTOSC' 'strict-dynamic';
object-src 'none';
base-uri 'none';<script nonce="LOSOWA_WARTOSC">
initApplication();
</script>Hash sprawdza się z kolei przy stałym fragmencie inline JavaScript. Musi odpowiadać dokładnej treści skryptu, dlatego nawet zmiana odstępu może wymagać aktualizacji polityki.
To obszar dla zespołu technicznego: nonce musi być generowany bezpiecznie dla każdej odpowiedzi, a sposób cache’owania HTML musi być z nim zgodny. Niedopasowanie nonce’a w HTML i w nagłówku zablokuje skrypt. Nie rozwiązuj tego pochopnie przez dodanie 'unsafe-inline'.
Jakie dyrektywy warto rozważyć?
default-src— punkt wyjścia dla wielu typów zasobów.script-src— źródła i zasady wykonywania JavaScript.style-src— arkusze stylów i style inline.img-srcorazfont-src— obrazy i fonty.connect-src— połączeniafetch, XHR, WebSocket, EventSource isendBeacon.frame-src— iframe’y ładowane przez stronę, np. płatności lub wideo.frame-ancestors— podmioty, które mogą osadzić Twoją stronę.form-action— dozwolone cele wysyłania formularzy.object-src 'none'ibase-uri 'none'— częste elementy polityki bazowej.
Nie każda dyrektywa jest potrzebna w każdej aplikacji. Dobieraj je do rzeczywistego modelu zasobów. Weryfikację struktury formularzy, komunikatów błędów i obsługi klawiaturą prowadź równolegle, zgodnie z poradnikiem Dostępny formularz: jak projektować i testować zgodnie z WCAG oraz materiałem Nawigacja klawiaturą: jak testować stronę zgodnie z WCAG.
Mini-scenariusz: CSP w sklepie z płatnością i widgetem
Scenariusz ilustracyjny — nie jest opisem wdrożenia klienta. Sklep działa na gotowym motywie, korzysta z zewnętrznej płatności, narzędzia analitycznego i skryptu WCAGbot dodanego jedną linią kodu. Zespół publikuje restrykcyjną regułę script-src 'self' bez trybu raportowania. Efekt: własne skrypty działają, ale checkout przestaje ładować iframe płatności, a panel widgetu nie otwiera się.
Poprawny następny krok nie polega na dodaniu znaku * do wszystkich dyrektyw. Zespół wraca do Report-Only, sprawdza naruszenia na każdej ścieżce zakupowej i potwierdza dokumentację aktualnych dostawców. Dopuszcza tylko wymagane źródła oraz tylko w dyrektywach odpowiadających ich funkcji. Na końcu testuje checkout, formularz, działanie na telefonie i nawigację klawiaturą.
Taki proces nie zastępuje audytu dostępności. Jeśli na stronie pozostają błędne etykiety pól, nieprawidłowe komunikaty błędów albo słaby kontrast strony, należy poprawić je w źródle. Podobnie automatycznie wykrywalne atrybuty nie rozwiązują wszystkich problemów semantyki i treści; kontekst użycia ARIA omawia artykuł ARIA w praktyce: kiedy wspiera dostępność strony.
Najczęstsze błędy przy CSP
- Włączenie enforcing bez Report-Only. Powoduje ryzyko nagłego zablokowania ważnej funkcji na produkcji.
- Dodanie
'unsafe-inline'jako szybkiej naprawy. Osłabia ochronę przed wykonywaniem inline JavaScript. - Wpisanie
data:doscript-srclub nadmiernie szerokich źródeł. Poszerza zakres dozwolonych treści bez wystarczającej kontroli. - Brak kontroli cache przy nonce’ach. Może prowadzić do niezgodności między nagłówkiem i HTML.
- Testowanie wyłącznie strony głównej. Najwięcej zależności zewnętrznych często występuje dopiero w logowaniu, koszyku i płatności.
- Mylenie CSP z audytem WCAG. CSP kontroluje zasoby; nie ocenia hierarchii nagłówków, tekstów alternatywnych ani jakości obsługi formularzy.
Podsumowanie dla zarządzającego i sprzedaży
Dla zarządzającego CSP jest kontrolą ryzyka, którą należy traktować jak proces utrzymaniowy, nie jednorazowy nagłówek. Właściciel biznesowy powinien wskazać krytyczne ścieżki, a techniczny — utrzymywać listę zatwierdzonych zależności oraz przeglądać raporty po zmianach.
Checklista testu CSP w sklepie internetowym
Dla sprzedaży i marketingu najważniejsza zasada brzmi: każdy nowy piksel, czat, formularz, system afiliacyjny lub skrypt partnera może wymagać zmiany CSP. Włącz zespół techniczny przed kampanią, a nie po zgłoszeniu błędu przez klienta. Jeśli równocześnie rozwijasz dostępność strony, zaplanuj funkcje wspierające użytkowników jako element testów regresji, obok koszyka i płatności.
FAQ: CSP — praktyczne pytania
Czy CSP zabezpiecza stronę przed każdym atakiem XSS?
Nie. CSP ogranicza skutki części scenariuszy XSS, ale nie usuwa błędów w aplikacji. Nadal potrzebujesz bezpiecznego renderowania danych, walidacji, sanitizacji i regularnego przeglądu kodu.
Czy CSP należy wdrażać nagłówkiem HTTP czy znacznikiem meta?
Preferowany jest nagłówek HTTP. Wariant meta http-equiv ma ograniczenia i nie obsługuje wszystkich możliwości CSP. Może być użyteczny w określonych aplikacjach statycznych, lecz nie powinien być domyślnym wyborem dla pełnej polityki.
Co robi Content-Security-Policy-Report-Only?
Raportuje naruszenia polityki, ale nie blokuje zasobów. Używaj go do testów i analizy zależności przed włączeniem egzekwowania CSP.
Dlaczego CSP blokuje skrypt inline?
Najczęściej dlatego, że script-src nie dopuszcza kodu inline. Bezpieczniejsze opcje to przeniesienie kodu do pliku zewnętrznego, zastosowanie nonce’a lub hasha. Dodanie 'unsafe-inline' jest kompromisem bezpieczeństwa.
Czy nonce można ustawić raz i przechowywać w konfiguracji?
Nie powinno się tego robić. Nonce musi być nieprzewidywalny i generowany dla odpowiedzi. Stała wartość nie spełnia celu tego mechanizmu.
Czy hash CSP nadaje się do każdego skryptu?
Nie. Hash jest wygodny dla stabilnego, niezmiennego kodu inline. Przy kodzie generowanym dynamicznie lub często modyfikowanym jego utrzymanie może być niewygodne; wtedy częściej rozważa się nonce.
Czy CSP może zablokować WCAGbot?
Tak. Jeżeli polityka nie dopuszcza zasobów wymaganych przez aktualną integrację, przeglądarka może zablokować skrypt, style lub połączenia widgetu. Sprawdź aktualną dokumentację integracji oraz testuj w trybie Report-Only przed publikacją enforcing.
Czy widget dostępności zastępuje audyt WCAG po wdrożeniu CSP?
Nie. Widget może wspierać użytkownika funkcjami takimi jak kontrast, powiększenie tekstu czy czytanie treści, ale nie zastępuje audytu, testów z użytkownikami ani trwałej naprawy barier w kodzie i treści. Plan działań znajdziesz w materiale Audyt WCAG i wdrożenie: praktyczny plan krok po kroku.
Czy frame-ancestors i frame-src oznaczają to samo?
Nie. frame-src określa, jakie iframe’y Twoja strona może ładować. frame-ancestors określa natomiast, które strony mogą osadzić Twoją stronę w iframe.
Jak sprawdzić, czy polityka CSP jest zbyt szeroka?
Przejrzyj źródła w każdej dyrektywie, usuń nieużywane domeny i unikaj szerokich reguł, takich jak * lub samo https:, jeśli nie są technicznie uzasadnione. Pomocniczo możesz skorzystać z narzędzia CSP Evaluator, ale wynik narzędzia nie zastępuje przeglądu architektury.
Jak często przeglądać CSP?
Po każdej zmianie dostawcy zewnętrznego, motywu, mechanizmu płatności, platformy analitycznej lub sposobu ładowania aplikacji. Warto także włączyć okresowy przegląd polityki do zwykłego procesu utrzymania strony.
Co zrobić teraz?
Zacznij od sprawdzenia aktualnych nagłówków strony i sporządzenia listy zasobów ładowanych na kluczowych podstronach. Następnie włącz tryb Report-Only, przejdź pełną ścieżkę zakupu i sprawdź, czy użytkownik nadal może obsłużyć stronę klawiaturą oraz skorzystać z funkcji wspierających dostępność.
Gdy chcesz dodać prosty pierwszy krok do dostępności bez przebudowy witryny, dodaj funkcje dostępności, przetestuj WCAGbot na własnym przykładzie i zaplanuj równolegle audyt oraz naprawę źródłową najważniejszych barier.
Źródła i materiały
- W3C Content Security Policy Level 3
- MDN Web Docs – Content Security Policy implementation
- HTTP Archive Web Almanac 2025 – Security
- MDN Web Docs – Content Security Policy
- NDSS Symposium – Complex Security Policy?
- developer.mozilla.org
- csp-evaluator.withgoogle.com
- almanac.httparchive.org
- cdn.httparchive.org
- developer.mozilla.org
- almanac.httparchive.org
- learn.microsoft.com
