Defaults.Exposed › Naprawy › Content-Security-Policy (CSP)

Jak naprawić Content-Security-Policy (CSP)

Polityka bezpieczeństwa treści (Content Security Policy) to reguła bezpieczeństwa, którą Twoja strona wręcza przeglądarce każdego odwiedzającego, mówiąc jej dokładnie, który kod wolno uruchomić. Bez niej, jeśli na stronę kiedykolwiek trafi coś złośliwego — przez pole komentarza, zhakowaną wtyczkę czy zewnętrzny skrypt — przeglądarka uruchomi to swobodnie, w tym kod po cichu zbierający numery kart i hasła Twoich klientów w trakcie wpisywania, z wciąż widoczną kłódką.

W skrócie dla Twojej firmy: Jeśli Twoja strona kiedykolwiek zostanie zmanipulowana, złośliwy kod może odczytać dane kart płatniczych i logowań Twoich klientów wprost z Twojego własnego koszyka, podczas gdy wszystko wygląda zupełnie normalnie — zostawiając Cię z obciążeniami zwrotnymi, roszczeniami z oszustw, naruszeniem danych podlegającym zgłoszeniu i niezaliczeniem kontroli, którego działy bezpieczeństwa większych klientów używają, by wstrzymać lub zabić transakcję.

Ile może Cię to kosztować

• Ukryty kod prześlizguje się na jedną z Twoich stron i po cichu kopiuje każdy numer karty i hasło, które Twoi klienci wpisują przy finalizacji, wysyłając je atakującemu, podczas gdy Twoja strona wygląda zupełnie normalnie — dowiadujesz się dopiero, gdy nadchodzą skargi o oszustwa.
• Oszust umieszcza fałszywy formularz «zapłać tutaj» na Twojej prawdziwej stronie, który przechwytuje płatności na jego własne konto; klienci sądzą, że zapłacili Tobie, obwiniają Cię, gdy towar nie nadchodzi, i żądają zwrotu pieniędzy.
• Dział bezpieczeństwa większego klienta skanuje Twoją stronę, widzi, że ta podstawowa ochrona jest wyłączona, i oznacza to — wstrzymując lub odbierając Ci kontrakt, dopóki nie udowodnisz, że to naprawione.
• Naruszenie przypisane do brakującego standardowego zabezpieczenia staje się incydentem podlegającym zgłoszeniu: pytania regulatora, powiadomienia klientów i cios w reputację, który kosztuje o wiele więcej niż darmowa naprawa.

Dlaczego to ma znaczenie. Kłódka dowodzi, że połączenie z Twoją stroną jest prywatne, ale nic nie robi, by kontrolować, jaki kod uruchamia się, gdy odwiedzający już jest na stronie. Polityka bezpieczeństwa treści to zabezpieczenie, które to robi — każe przeglądarkom ignorować każdy skrypt, który nie pochodzi ze źródła, któremu ufasz, by pojedyncze zmanipulowane pole, reklama czy wtyczka nie mogły zostać zamienione w narzędzie do kradzieży pieniędzy i danych Twoich klientów. To oceniana kontrola na Twojej karcie wyników, warta realnych punktów, i jedna z pierwszych rzeczy, których szuka profesjonalna kontrola bezpieczeństwa.

Czym to jest, prostymi słowami

Gdy ktoś odwiedza Twoją stronę, jego przeglądarka pobiera Twoją stronę i uruchamia jakikolwiek kod na niej jest — skrypty, które rozwijają menu, sprawiają, że przyciski działają, formularze płatności się wysyłają itd. Domyślnie przeglądarka ufa temu wszystkiemu. Nie ma jak wiedzieć, który kod jest naprawdę Twój, a który przemycił ktoś inny.

Polityka bezpieczeństwa treści (często skracana do CSP) to krótka lista reguł, którą Twoja strona dołącza do każdej strony, mówiąc przeglądarce: „uruchamiaj tylko kod ze źródeł, które zatwierdziłem, a wszystko inne odmów”. To różnica między klubem nocnym, który wpuszcza każdego, a takim z listą gości przy drzwiach.

Powodem, dla którego to tak ważne, jest to, że strony są manipulowane bez przerwy — nie zawsze przez zhakowanie Twojego serwera, ale przez tylne furtki, które większość stron zostawia otwarte: pole komentarza, pole wyszukiwania, przestarzała wtyczka, zewnętrzny skrypt do reklam lub analityki albo widżet czatu. Jeśli atakujący wprowadzi choć jedną linię własnego kodu na jedną z Twoich stron, przeglądarka uruchomi ją, jakby była Twoja. Stamtąd może odczytać wszystko, co wpisują Twoi klienci — numery kart, hasła, adresy — i po cichu wysłać to gdzie indziej. Polityka bezpieczeństwa treści zatrzaskuje te drzwi, odmawiając uruchomienia czegokolwiek ze źródła, którego nie zatwierdziłeś.

Ile może Cię to kosztować

To nie abstrakcja. Atak, któremu polityka bezpieczeństwa treści zapobiega — kod wstrzyknięty na stronę, który kradnie dane od Twoich własnych klientów — stoi za niektórymi z największych odnotowanych naruszeń z podbieraniem kart. Oto jak zwykle rozgrywa się to dla normalnej firmy:

• Niewidzialny skimmer w koszyku. Atakujący wsuwa kilka linii kodu na Twoją stronę finalizacji przez podatną wtyczkę lub przejęty zewnętrzny skrypt. Każdy numer karty, nazwisko i CVV, które wpisują Twoi klienci, jest kopiowany i wysyłany atakującemu w czasie rzeczywistym. Twoja strona wygląda i działa idealnie; kłódka jest na miejscu. Odkrywasz to tygodnie później, gdy Twój dostawca płatności dzwoni o skupisku zgłoszeń oszustw, wszystkie prowadzące z powrotem do Twojego sklepu. Teraz stoisz wobec obciążeń zwrotnych, wymuszonego audytu bezpieczeństwa, możliwej utraty prawa do przetwarzania kart i naruszenia, które być może masz prawny obowiązek zgłosić.

• Fałszywy formularz płatności. Oszust wstrzykuje przekonujące okienko „zapłać tutaj” na Twoją prawdziwą stronę. Klienci wpisują dane, ufając Twojej marce; pieniądze i dane idą do atakującego. Klienci obwiniają Ciebie — i nie bez racji, bo stało się to na Twojej stronie.

• Utracony kontrakt. Dział bezpieczeństwa większego potencjalnego klienta przeprowadza automatyczny skan Twojej strony w ramach due diligence dostawcy. Brakująca polityka bezpieczeństwa treści pojawia się natychmiast jako luka wysokiej wagi. Dla recenzenta zakupowego lub bezpieczeństwa to jedno brakujące zabezpieczenie czyta się jako „ten dostawca nie robi podstaw” — a transakcja utyka, gdy proszą o naprawę, albo po cichu idzie do konkurenta, który przeszedł.

• Naruszenie podlegające zgłoszeniu. Gdy naruszenie danych zostaje przypisane brakującemu, standardowemu, darmowemu zabezpieczeniu, przestaje być pechem, a zaczyna wyglądać na zaniedbanie. To zmienia pytania regulatora, obowiązek powiadomienia klientów i koszt — zarówno karę, jak i szkody reputacyjne, które ciągną się długo po zamknięciu incydentu.

• Przejęta reklama lub widżet. Wiele stron wczytuje kod od stron zewnętrznych — sieci reklamowe, czcionki, czat wsparcia, analityka. Jeśli którakolwiek z nich zostanie naruszona, złośliwy kod wjeżdża prosto na Twoje strony. Polityka bezpieczeństwa treści ogranicza promień rażenia, dopuszczając tylko konkretne zewnętrzne źródła, którym ufasz, więc naruszenie jednego dostawcy nie staje się automatycznie Twoim.

Czym to właściwie jest (szczegóły)

Polityka bezpieczeństwa treści jest dostarczana jako pojedynczy nagłówek odpowiedzi HTTP — linia, którą Twój serwer WWW wysyła z każdą stroną. Jej wartość to zestaw dyrektyw, każda nazywająca typ treści i dozwolone dla niej źródła. Na przykład:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

W prostych słowach mówi to: domyślnie wczytuj rzeczy tylko z mojej własnej strony; uruchamiaj skrypty tylko z mojej własnej strony; nie dopuszczaj starych wtyczek; i nie pozwól innym stronom osadzać mojej w ramce.

Jak wygląda „dobrze”. Nasza kontrola nie szuka tylko obecności nagłówka — czyta politykę dyrektywa po dyrektywie i ocenia, jak silna faktycznie jest, tak jak zrobiłby recenzent bezpieczeństwa. Silna polityka:

• Ustawia restrykcyjny punkt wyjścia (default-src 'self') i poszerza go tylko o konkretne zaufane strony zewnętrzne, których naprawdę używasz.
• Unika furtek. Nie używa 'unsafe-inline' ani 'unsafe-eval' dla skryptów i nie używa wieloznacznika (*) ani gołych źródeł schematu (jak https:) dla skryptów — te w praktyce ponownie otwierają drzwi, które polityka ma zamknąć. Tam, gdzie skrypty wbudowane są naprawdę potrzebne, używa nonce lub hasza, by uruchomił się tylko Twój konkretny zatwierdzony kod.
• Rygluje osadzanie przez frame-ancestors 'self' (to też blokuje atak „osadź swoją stronę, by oszukać klientów”) i wyłącza starsze wtyczki przez object-src 'none'.
• Jest egzekwująca, nie report-only. Nagłówek Content-Security-Policy-Report-Only tylko obserwuje; daje zerową ochronę w czasie działania. Nasza kontrola daje mu drobny ułamek kredytu i nigdy nie zapisuje tego jako zaliczenia. Jesteś chroniony dopiero, gdy polityka jest egzekwująca.

Polityka, która istnieje, ale opiera się na 'unsafe-inline', 'unsafe-eval' lub wieloznacznikach, wciąż wypadnie słabo — bo w praktyce daje niewiele realnej ochrony. Celem jest ścisła polityka, a nie byle jaka.

Jak to naprawić (za darmo, ~1–2 godziny)

Przekaż to swojemu informatykowi lub osobie prowadzącej Twoją stronę — sama naprawa jest całkowicie darmowa. My pobieramy opłatę jedynie za monitorowanie, że pozostaje na miejscu i poprawna w czasie; włączenie nic nie kosztuje. Powodem, dla którego zajmuje to godzinę czy dwie, a nie minuty, jest ostrożny krok próbny, który zapobiega przypadkowemu zablokowaniu części Twojej własnej strony.

1. Zacznij w trybie report-only — jeszcze nie egzekwuj. Dodaj nagłówek odpowiedzi Content-Security-Policy-Report-Only. To obserwuje i loguje, co zostałoby zablokowane, faktycznie niczego nie blokując, więc żywa strona wciąż działa, podczas gdy uczysz się, od czego każda strona naprawdę zależy. (Ważne: report-only sam w sobie nie daje odwiedzającym ochrony — to tylko bezpieczny pierwszy krok.)

2. Zbuduj politykę z tego, czego strona faktycznie używa. Przejrzyj raporty, by znaleźć każde prawowite źródło skryptów, stylów, czcionek i obrazów — Twoją własną domenę, Twoją analitykę, Twojego dostawcę płatności, host czcionek, widżet czatu — i wypisz je jako dozwolone źródła. Solidny punkt wyjścia to default-src 'self' plus jawne wpisy dla zaufanych stron zewnętrznych, których naprawdę używasz.

3. Unikaj furtek, które niweczą cały sens. Trzymaj się z daleka od 'unsafe-inline' i 'unsafe-eval' dla skryptów i unikaj wieloznacznych źródeł jak * oraz gołych schematów jak https: dla skryptów — te ponownie otwierają dokładnie tę lukę, którą polityka ma zamknąć. Tam, gdzie skrypty wbudowane są nieuniknione, użyj nonce lub hasza, by uruchomił się tylko Twój konkretny zatwierdzony kod.

4. Zarygluj osadzanie i wtyczki. Dodaj frame-ancestors 'self' (to też powstrzymuje inne strony przed osadzaniem Twojej, by oszukać klientów, i spełnia powiązaną kontrolę clickjackingu) oraz object-src 'none', by zablokować ataki oparte na starszych wtyczkach.

5. Przełącz z report-only na egzekwujący. Gdy raporty są czyste, a strona działa, zmień nazwę nagłówka z Content-Security-Policy-Report-Only na Content-Security-Policy. To krok, który faktycznie dostarcza ochronę — sama polityka report-only jej nie daje i nie przejdzie kontroli.

   Gdzie ustawiasz nagłówek, zależy od Twojej platformy:

   • Cloudflare: Rules → Transform Rules → Modify Response Header → ustaw Content-Security-Policy. (Możesz użyć Cloudflare także do próby report-only.)
   • Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
   • Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
   • IIS (web.config): dodaj niestandardowy nagłówek odpowiedzi HTTP o nazwie Content-Security-Policy z polityką jako wartością.
   • Google Workspace / Microsoft 365: te prowadzą Twoją pocztę, nie publiczną stronę, więc polityka jest ustawiana tam, gdzie strona jest faktycznie hostowana (Cloudflare lub Twój host WWW powyżej), a nie w panelu administracyjnym poczty.

6. Sprawdź ponownie swoją domenę, by potwierdzić, że polityka pokazuje się teraz jako włączona i egzekwująca, bez osłabiających furtek.

Częste błędy

• Zatrzymanie się na report-only. Pojedynczy najczęstszy błąd: polityka jest dodana w trybie report-only, wszyscy idą dalej, a strona nigdy nie jest faktycznie chroniona. Report-only niczego nie blokuje. Musisz przełączyć na egzekwujący.
• Sięganie po 'unsafe-inline', by «po prostu działało». Gdy polityka blokuje prawowity skrypt wbudowany, szybkim obejściem jest dopuszczenie wszystkich skryptów wbudowanych — ale to ponownie otwiera dokładnie tę dziurę, którą polityka miała zamknąć. Użyj zamiast tego nonce lub hasza.
• Użycie wieloznacznika. Gołe * (lub https:) w script-src dopuszcza skrypty skądkolwiek, co oznacza, że polityka daje niemal żadnej realnej ochrony i wciąż wypadnie nisko.
• Zapomnienie o źródłach zewnętrznych. Egzekwowanie ścisłej polityki bez wcześniejszego wypisania prawowitych usług zewnętrznych, których używasz (analityka, czcionki, widżety płatności), może zepsuć części Twojej własnej strony — i właśnie dlatego istnieje krok próbny report-only.
• Ustawienie tego tylko na stronie głównej. Polityka musi obejmować każdą stronę, zwłaszcza strony finalizacji, logowania i konta — to one są warte atakowania.
• Traktowanie tego jako zamiennika kłódki. Polityka bezpieczeństwa treści i HTTPS/HSTS chronią różne rzeczy. Chcesz ich wszystkich; jedno nie zastępuje drugiego.

Najczęstsze pytania