Jak działa ta kontrola
Ta kontrola działa tylko wtedy, gdy Twoja strona już wysyła nagłówek Content-Security-Policy; jeśli go nie wysyła, oznacza to skaner nagłówków. Scanaris czyta całą politykę i szuka dwóch słów, które ją wydrążają: 'unsafe-inline', pozwalającego wykonać dowolny skrypt lub styl wpisany bezpośrednio w HTML, oraz 'unsafe-eval', pozwalającego zamieniać tekst w kod przez eval i podobne. Jeśli któreś się pojawia, otwiera znalezisko o niskiej wadze z listą znalezionych słabości. Niska, bo niedoskonałe CSP wciąż jest lepsze niż jego brak, ale ochrona przed wstrzykiwaniem skryptów, czyli racja bytu CSP, zostaje niemal zniesiona.
Dlaczego to ważne
Ścisłe CSP sprawia, że nawet jeśli atakujący zdoła wstawić <script> do Twojej strony (przez nieoczyszczony komentarz, odbity parametr albo skompromitowaną bibliotekę), przeglądarka odmówi jego wykonania. Z 'unsafe-inline' w script-src ten wstrzyknięty skrypt wykonuje się mimo wszystko: nagłówek jest, kłódka wygląda na zamkniętą, ale drzwi są otwarte. Liczy się, gdzie stoi to słowo: w script-src jest poważnie; w style-src to dużo mniejsze ryzyko, które wiele stron akceptuje ze względu na style inline.
Jak to naprawić
1. Nonce dla skryptów inline
Nonce to losowa wartość, inna przy każdym żądaniu, którą umieszczasz w nagłówku i w każdym legalnym tagu <script>. Przeglądarka wykonuje tylko skrypty z tą wartością; wstrzyknięty skrypt jej nie zna.
Content-Security-Policy: script-src 'nonce-R4nd0m' 'strict-dynamic'; object-src 'none'; base-uri 'self'Next.js robi to w middleware, generując nonce i przekazując go do nagłówka i komponentów; Nuxt przez wtyczkę serwerową, która wstrzykuje go do każdej odpowiedzi (tak robi Scanaris); Express przez middleware, który zapisuje go w res.locals i wypisuje w szablonach.
2. Hashe dla stałych skryptów
Jeśli skrypt inline nigdy się nie zmienia, policz jego hash SHA-256 i wstaw go do polityki: 'sha256-…'. Sprawdza się dla małych fragmentów, jak ten od menedżera tagów, bez stawiania nonce'ów.
3. Przeniesienie kodu do plików
Handlery onclick="…" i bloki skryptów w HTML-u to typowy powód potrzeby 'unsafe-inline'. Przenieś je do plików .js serwowanych z Twojej domeny, a potrzeba znika.
4. Usunięcie unsafe-eval
Zwykle wymaga go stara biblioteka albo tryb deweloperski frameworka, który wkradł się na produkcję. Sprawdź w konsoli przeglądarki, co o niego prosi, i zaktualizuj albo zastąp ten element.
5. Wdrożenie w trybie raportowania
Opublikuj nową politykę najpierw jako Content-Security-Policy-Report-Only z dyrektywą report-to lub report-uri wskazującą na Twój endpoint. Przez kilka dni zbieraj, co by blokowała, dopasuj, a gdy raporty będą czyste, zmień ją na nagłówek blokujący.
Sprawdź, czy naprawione
curl -sI https://twojadomena.com | grep -i "content-security-policy"W script-src nie może pojawić się ani 'unsafe-inline', ani 'unsafe-eval'. Potem przejdź po stronie z otwartą konsolą: każda blokada pojawia się tam z dyrektywą, która ją spowodowała. Pełna teoria jest w nagłówki bezpieczeństwa HTTP wyjaśnione dla ludzi.
Często zadawane pytania
Używam Tailwinda lub stylów inline. Czy muszę usunąć unsafe-inline ze style-src?
Pożądane, ale niepilne. Style inline nie wykonują kodu. Priorytet ma script-src; polityka z 'unsafe-inline' tylko w style-src chroni przed tym, co istotne.
Google Tag Manager albo czat wsparcia zmuszają mnie do rozluźnienia polityki.
Prawie wszystkie mają dokumentację CSP: akceptują nonce albo publikują hashe i domeny, których potrzebują. Dodaj ich originy do script-src i connect-src, zamiast otwierać wszystko.
Czy CSP zepsuje mi stronę?
Tylko jeśli przełączysz ją na blokowanie bez testów. Po to jest tryb raportowania: pokazuje, co by się zepsuło, nie psując tego.