Co to jest CSP?
Autor: Redakcja Domeny.ForSale Opublikowano
W skrócie: CSP, czyli Content Security Policy, to mechanizm bezpieczeństwa przeglądarki, który pozwala określić, skąd strona może pobierać zasoby i jaki kod może wykonywać. Pomaga ograniczać skutki XSS, czyli wstrzyknięcia obcego skryptu do strony, a odpowiednia dyrektywa chroni także przed osadzaniem witryny w niepożądanych ramkach. Politykę najlepiej przekazywać w nagłówku odpowiedzi HTTP i najpierw przetestować bez blokowania zasobów.
Jak działa CSP i przed czym chroni?
Przeglądarka zwykle pobiera zasoby wskazane w kodzie strony: skrypty, arkusze stylów, obrazy czy fonty. CSP dodaje do tego zestaw reguł. Jeżeli zasób lub sposób wykonania kodu nie spełnia polityki, przeglądarka go blokuje i zapisuje informację o naruszeniu w narzędziach deweloperskich.
Najważniejszym zastosowaniem CSP jest ograniczanie ataków XSS (cross-site scripting). Taki atak polega na doprowadzeniu do wykonania skryptu napastnika w kontekście cudzej witryny. Przykładowo luka w formularzu komentarzy może umożliwić wstawienie kodu JavaScript zamiast zwykłego tekstu. Odpowiednio restrykcyjna CSP może uniemożliwić wykonanie tego kodu, nawet jeśli aplikacja błędnie umieści go na stronie.
CSP pomaga też przeciwdziałać clickjackingowi: osadzeniu strony w ramce i nakłonieniu użytkownika do kliknięcia jej elementów pod mylącą nakładką. Odpowiada za to dyrektywa frame-ancestors. Samo ustawienie reguł dla skryptów nie zapewnia tej ochrony.
CSP nie naprawia jednak luk aplikacji. Nadal potrzebne są poprawne kodowanie danych wyjściowych, bezpieczne przetwarzanie treści użytkowników i aktualizacje oprogramowania. Polityka jest dodatkową warstwą ochrony, a nie zamiennikiem tych działań.
Gdzie ustawia się politykę CSP?
Zalecanym miejscem jest nagłówek odpowiedzi HTTP o nazwie Content-Security-Policy. Może go dodawać aplikacja, serwer WWW, reverse proxy albo CDN. Nagłówek powinien trafiać do przeglądarki razem z dokumentem HTML, którego ma dotyczyć.
Część reguł można również przekazać przez znacznik meta z atrybutem http-equiv="Content-Security-Policy". To rozwiązanie ma ograniczenia: polityka zaczyna działać dopiero po odczytaniu znacznika, nie obsługuje trybu raportowania bez blokowania ani dyrektywy frame-ancestors. Jeśli masz dostęp do konfiguracji odpowiedzi HTTP, wybierz nagłówek.
Sprawdź też, czy CSP nie jest już dodawana przez inną warstwę infrastruktury. Kilka polityk jest egzekwowanych jednocześnie — kolejny nagłówek nie zastępuje automatycznie poprzedniego. Może więc dodatkowo ograniczyć działanie strony.
Najważniejsze dyrektywy i przykład nagłówka
Dyrektywa to pojedyncza reguła polityki. Poszczególne dyrektywy oddziela się średnikami, a po ich nazwach podaje dozwolone źródła lub specjalne wartości.
| Dyrektywa | Co kontroluje |
|---|---|
default-src | Domyślne źródła dla wielu typów zasobów, jeśli nie mają własnej reguły |
script-src | Źródła skryptów i warunki wykonywania JavaScript |
style-src | Źródła arkuszy stylów i zasady używania stylów osadzonych |
img-src | Źródła obrazów |
connect-src | Połączenia inicjowane m.in. przez fetch i WebSocket |
object-src | Osadzane obiekty obsługiwane przez elementy takie jak object |
base-uri | Adresy dopuszczone w elemencie base |
frame-ancestors | Strony, które mogą osadzać dokument w ramce |
Dla prostej witryny korzystającej wyłącznie z własnych plików punktem wyjścia może być:
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Wartość 'self' oznacza to samo pochodzenie: zgodny schemat, nazwę hosta i port. 'none' nie dopuszcza żadnego źródła. Powyższy przykład zabrania osadzania strony w ramkach oraz blokuje między innymi skrypty wpisane bezpośrednio w HTML i atrybuty zdarzeń, takie jak onclick.
To nie jest uniwersalna konfiguracja. Jeżeli strona używa zewnętrznego systemu płatności, analityki albo fontów, trzeba ustalić wymagane źródła i dodać je do właściwych dyrektyw. default-src nie zastępuje wszystkich reguł — na przykład frame-ancestors wymaga osobnej deklaracji.
Jak wdrożyć CSP bez przypadkowego blokowania strony?
Najbezpieczniej zacząć od poznania rzeczywistych zależności witryny, a dopiero później włączyć blokowanie.
- Spisz zasoby i integracje. Uwzględnij nie tylko stronę główną, lecz także logowanie, formularze, płatności i panel użytkownika.
- Ustaw nagłówek
Content-Security-Policy-Report-Only. Przeglądarka oceni proponowaną politykę i zgłosi naruszenia, ale ich nie zablokuje. Automatyczne zbieranie raportów wymaga dodatkowej konfiguracji mechanizmu raportowania i odbiornika. - Przetestuj pełne scenariusze użytkownika. Sprawdź konsolę oraz panel sieciowy przeglądarki. Odróżnij potrzebne zasoby od zbędnych integracji i żądań pochodzących z rozszerzeń przeglądarki.
- Popraw reguły i kod. Po testach przełącz sprawdzoną politykę na
Content-Security-Policy, a po wdrożeniu monitoruj błędy.
Nie usuwaj ostrzeżeń przez bezrefleksyjne dodawanie *, 'unsafe-inline' czy 'unsafe-eval'. Takie wyjątki mogą istotnie osłabić ochronę. Dla potrzebnych skryptów osadzonych można stosować nonce — nieprzewidywalną wartość generowaną dla każdej odpowiedzi — albo hash, czyli skrót zawartości konkretnego skryptu. Nonce musi zgadzać się w nagłówku i elemencie skryptu; stała wartość wklejona do konfiguracji nie spełnia tego zadania.
Zacznij od polityki w trybie raportowania na środowisku testowym i wykonaj pełną ścieżkę od wejścia na stronę do wysłania formularza lub zakończenia zakupu. To pokaże, jakie uprawnienia są rzeczywiście potrzebne, zanim CSP zacznie blokować zasoby użytkownikom.
Zobacz też: Co to jest MCP?
Przeczytaj także
