Dlaczego SRI jest konieczne, jeśli już korzystam z HTTPS?

HTTPS chroni skrypt podczas przesyłania między CDN a przeglądarką. Nie chroni przed naruszeniem samego CDN. CDN obsługujący złośliwy skrypt za pośrednictwem doskonale prawidłowego połączenia TLS jest dokładnie tym, przed czym chroni SRI.

Czy muszę określać SRI w każdym skrypcie?

W przypadku skryptów zewnętrznych tak — w tym właśnie tkwi wartość. Skrypty hostowane na własnym serwerze nie korzystają tak bardzo z SRI (jeśli Twoje źródło zostanie naruszone, sama strona również). Większość nowoczesnych konfiguracji stosuje SRI do zasobów hostowanych w CDN.

Co się stanie, jeśli moja biblioteka będzie często aktualizowana?

Zablokuj określoną wersję i zaktualizuj razem wersję + skrót. Automatyczna aktualizacja do „najnowszej” jest sprzeczna z SRI. W przypadku większości zakładów produkcyjnych przypięte wersje są i tak właściwym wyborem — automatyczne aktualizacje zależności spowodowały rzeczywiste incydenty produkcyjne.

Czy atakujący mogą ominąć SRI?

Nie na poziomie protokołu — matematyka jest solidna. Praktyczne obejścia wynikają z błędnej konfiguracji: braku atrybutu crossorigin (w niektórych scenariuszach powoduje otwarcie awaryjne) lub atakującego kontrolującego samą stronę (w takim przypadku nie muszą omijać SRI; usuwają go).

Czy powinienem używać SHA-256, SHA-384 czy SHA-512?

Przeglądarki obsługują wszystkie trzy. Powszechnym wyborem jest SHA-384 — nieco większa odporność na kolizje niż SHA-256, a jednocześnie krótsza niż SHA-512. Bezpieczeństwo praktyczne jest porównywalne; wybierz jeden i używaj go konsekwentnie.

Wyjaśnienie integralności podzasobów: jak strony weryfikują ładowane skrypty

Każdy znacznik skryptu wskazujący na sieć CDN jest relacją zaufania z tą siecią CDN. Jeśli CDN zostanie naruszony lub wymuszony, skrypt dostarczony odwiedzającym ulegnie zmianie — a oni otrzymają to, co obecnie obsługuje CDN. Subresource Integrity to funkcja przeglądarki, która przypina każdy skrypt do skrótu kryptograficznego, dzięki czemu wykrywane są wszelkie manipulacje i skrypt jest odrzucany.

Poniżej znajduje się pełna treść artykułu w języku angielskim.

Subresource Integrity (SRI) to funkcja zabezpieczeń, która umożliwia stronie internetowej określenie skrótu kryptograficznego dla każdego ładowanego zasobu zewnętrznego. Przeglądarka pobiera zasób, miesza go i porównuje z oczekiwaną wartością. Jeśli skrót nie jest zgodny, zasób jest odrzucany.

Standardowany przez W3C SRI w 2016 r. Wdrożenie trwało lata i obecnie jest powszechne — główne witryny i sieci CDN powszechnie go obsługują.

Zagrożenie Adresy SRI

Bez SRI, ładowanie strony ufa, że CDN dostarczy dokładnie to, czego oczekiwano. Problemy:

CDN kompromis. Jeśli atakujący przejmie sieć CDN, każda witryna ładująca z niej skrypty otrzyma zamiast tego kod atakującego.
Wymuszone CDN. Nakaz rządowy wydany operatorowi CDN może wymusić dostarczenie zmodyfikowanych skryptów określonym użytkownikom lub regiony.
Atak poufny. Pracownik CDN, usługi hostingowej biblioteki lub zewnętrznego źródła pakietu modyfikuje plik. Bez SRI każdy dalszy konsument ładuje zmodyfikowaną wersję.
Przejęcie konta. Konto autora biblioteki zostało przejęte; nowe wersje przesyłają złośliwy kod, który jest automatycznie wykrywany przez witryny.

SRI nie zapobiega tym zagrożeniom, ale uniemożliwia im dotarcie do odwiedzających.

Jak działa syntaktycznie SRI

Atrybut integralności przechowuje algorytm (tutaj sha384; obsługiwane są także sha256 i sha512) oraz skrót zakodowany w formacie base64. Atrybut crossorigin jest wymagany, aby przeglądarka mogła używać CORS do pobrania i sprawdzenia zasobu.

Jeśli skrót pobranego skryptu jest zgodny, zostanie uruchomiony. Jeśli nie, przeglądarka zarejestruje błąd konsoli i nie wykona skryptu. Strona może się zepsuć, ale nie uruchamia niezaufanego kodu.

Co SRI chroni, a czego nie

SRI chroni przed nieoczekiwaną modyfikacją określonego zasobu. To nie:

Uniemożliwia legalnemu wydawcy zmianę zasobu (poprzez odpowiednią aktualizację skrótu).
Chroń zasoby bez atrybutów integralności — większość stron ma setki zasobów; SRI w bibliotece głównej nie pomaga, jeśli ładowane są także inne niezweryfikowane skrypty.
Ochrona przed lukami w samym zasobie.
Zastosuj do dynamicznie ładowanych skryptów (możesz weryfikować skróty ręcznie, ale wymaga to niestandardowego kodu).

Przypinanie wersji kompromis

SRI łączy zasób z określoną wersją. Jeśli potrzebujesz „najnowszej wersji pomocniczej” z automatycznymi aktualizacjami poprawek błędów, SRI nie pasuje — każda zmiana w zasobie wymaga aktualizacji skrótu. Wybór jest następujący:

Przypnij do określonej wersji za pomocą SRI w celu wykrywania manipulacji
Użyj źródeł automatycznej aktualizacji bez SRI i zaufaj dostawcy

W przypadku witryn o dużej wartości przypinanie wersji za pomocą SRI jest bezpieczniejszym rozwiązaniem domyślnym. W przypadku witryn, w których automatyczne poprawianie zabezpieczeń biblioteki jest ważniejsze niż wykrywanie manipulacji (rzadko), kompromis idzie w drugą stronę.

SRI i CSP razem

SRI w naturalny sposób łączą się z Polityką bezpieczeństwa treści. CSP może określić require-sri-dla stylu skryptu, co powoduje, że przeglądarka odmawia załadowania jakiegokolwiek skryptu lub arkusza stylów bez atrybutu integralności. Wymusza to użycie SRI na poziomie polityki, zapobiegając przypadkowemu pominięciu.

Połączenie — CSP + SRI + odpowiednie ograniczenia pochodzenia — to nowoczesny przepis na wzmocnione strony internetowe.

Rzeczywistość operacyjna

SRI jest dobrze obsługiwana przez przeglądarki (Chrome, Firefox, Safari, Edge) i główne sieci CDN (jsDelivr, cdnjs, unpkg wszystkie zapewniają skróty SRI dla hostowanych bibliotek). Główną barierą w przyjęciu jest złożoność operacyjna:

Każda wersja biblioteki ma swój własny skrót
Aktualizacja biblioteki oznacza generowanie nowego skrótu i aktualizację każdej strony, która się do niej odwołuje
Potoki kompilacji muszą uwzględniać generowanie skrótu dla zasobów hostowanych samodzielnie
Kompilacje dynamiczne, w których Zmiany pakietu JS na wdrożenie wymagają automatycznego mieszania SRI na etapie kompilacji

Główne frameworki (webpack, Vite, parcel, esbuild) zawierają wtyczki SRI do obsługi mieszania w czasie kompilacji. W przypadku typowych aplikacji jest to jednorazowe zadanie konfiguracyjne.

SRI w 2026

Ta funkcja jest obecnie podstawą dla witryn dbających o bezpieczeństwo. Pozostała luka polega na tym, że niektóre popularne biblioteki są ładowane z wielu sieci CDN z różnymi wersjami; narzędzia do śledzenia i rozpowszechniania aktualizacji skrótu zostały ulepszone, ale nadal wymagają uwagi.

W przypadku użytkowników funkcja SRI działa po cichu w wielu witrynach odwiedzanych codziennie. Przeglądarka automatycznie przeprowadza weryfikację. Zauważasz to tylko wtedy, gdy coś się psuje — zwykle z powodu braku synchronizacji skrótu po aktualizacji biblioteki.

Często zadawane pytania

Dlaczego SRI jest konieczne, jeśli już korzystam z HTTPS?: HTTPS chroni skrypt podczas przesyłania między CDN a przeglądarką. Nie chroni przed naruszeniem samego CDN. CDN obsługujący złośliwy skrypt za pośrednictwem doskonale prawidłowego połączenia TLS jest dokładnie tym, przed czym chroni SRI.
Czy muszę określać SRI w każdym skrypcie?: W przypadku skryptów zewnętrznych tak — w tym właśnie tkwi wartość. Skrypty hostowane na własnym serwerze nie korzystają tak bardzo z SRI (jeśli Twoje źródło zostanie naruszone, sama strona również). Większość nowoczesnych konfiguracji stosuje SRI do zasobów hostowanych w CDN.
Co się stanie, jeśli moja biblioteka będzie często aktualizowana?: Zablokuj określoną wersję i zaktualizuj razem wersję + skrót. Automatyczna aktualizacja do „najnowszej” jest sprzeczna z SRI. W przypadku większości zakładów produkcyjnych przypięte wersje są i tak właściwym wyborem — automatyczne aktualizacje zależności spowodowały rzeczywiste incydenty produkcyjne.
Czy atakujący mogą ominąć SRI?: Nie na poziomie protokołu — matematyka jest solidna. Praktyczne obejścia wynikają z błędnej konfiguracji: braku atrybutu crossorigin (w niektórych scenariuszach powoduje otwarcie awaryjne) lub atakującego kontrolującego samą stronę (w takim przypadku nie muszą omijać SRI; usuwają go).
Czy powinienem używać SHA-256, SHA-384 czy SHA-512?: Przeglądarki obsługują wszystkie trzy. Powszechnym wyborem jest SHA-384 — nieco większa odporność na kolizje niż SHA-256, a jednocześnie krótsza niż SHA-512. Bezpieczeństwo praktyczne jest porównywalne; wybierz jeden i używaj go konsekwentnie.