De ce este necesar SRI dacă folosesc deja HTTPS?

HTTPS protejează scriptul în tranzit între CDN și browser. Nu protejează împotriva compromisului CDN-ului în sine. CDN-ul care vă oferă un script rău intenționat printr-o conexiune TLS perfect validă este exact ceea ce SRI se apără.

Trebuie să specific SRI pe fiecare script?

Pentru scripturile externe, da — acolo este valoarea. Scripturile auto-găzduite pe propria ta origine nu beneficiază la fel de mult de SRI (dacă originea ta este compromisă, și pagina în sine). Cele mai multe configurații moderne aplică SRI resurselor găzduite de CDN.

Ce se întâmplă dacă biblioteca mea se actualizează frecvent?

Blocați o anumită versiune și actualizați împreună versiunea + hash. Actualizarea automată la „cele mai recente” este în contradicție cu SRI. Pentru majoritatea site-urilor de producție, versiunile fixate sunt oricum alegerea potrivită - actualizările automate ale dependențelor au cauzat incidente reale de producție.

Pot atacatorii să ocolească SRI?

Nu la nivel de protocol - matematica este solidă. Ocolirile practice provin din configurarea greșită: lipsa atributului de origine încrucișată (determină deschiderea eșuată în unele scenarii) sau atacatorul care controlează pagina în sine (caz în care nu trebuie să ocolească SRI; îl elimină).

Ar trebui să folosesc SHA-256, SHA-384 sau SHA-512?

Browserele acceptă toate trei. SHA-384 este alegerea comună - rezistență la coliziune puțin mai puternică decât SHA-256, dar mai scurtă decât SHA-512. Securitatea practică este comparabilă; alege unul și folosește-l în mod constant.

Integritatea subresursei explicată: Cum verifică paginile scripturile pe care le încarcă

Fiecare etichetă de script care indică un CDN este o relație de încredere cu acel CDN. Dacă CDN-ul este compromis sau constrâns, scriptul livrat vizitatorilor tăi se schimbă - și aceștia primesc orice servește acum CDN-ul. Integritatea subresursei este caracteristica browserului care fixează fiecare script într-un hash criptografic, astfel încât orice manipulare este detectată și scriptul este refuzat.

Întregul articol al articolului este oferit în limba engleză mai jos.

Subresource Integrity (SRI) este o caracteristică de securitate care permite unei pagini web să specifice un hash criptografic pentru fiecare resursă externă pe care o încarcă. Browserul preia resursa, o stochează și o compară cu valoarea așteptată. Dacă hash-ul nu se potrivește, resursa este respinsă.

SRI-ul standardizat de W3C în 2016. Adopția a durat ani de zile și acum este largă — site-urile majore și CDN-urile îl acceptă pe scară largă.

Amenințarea SRI se adresează

Fără SRI, o pagină de încărcare

Atributul de integritate deține algoritmul (sha384 aici; sha256 și sha512 sunt de asemenea acceptate) și hash-ul codificat în base64. Atributul crossorigin este necesar, astfel încât browserul să poată utiliza CORS pentru a prelua și verifica resursa.

IDacă hash-ul scriptului preluat se potrivește, acesta rulează. Dacă nu, browserul înregistrează o eroare de consolă și nu execută scriptul. Pagina se poate rupe, dar nu rulează cod neîncrezat.

Ce protejează SRI și nu

SRI protejează împotriva modificării neașteptate a resursei specifice. Nu:

Previne editorul legitim să modifice resursa (cu o actualizare hash corespunzătoare).
Protejează resursele fără atribute de integritate — majoritatea paginilor au sute de resurse; SRI din biblioteca principală nu ajută dacă sunt încărcate și alte scripturi neverificate.
Apărați-vă împotriva vulnerabilităților din resursa în sine.
Aplicați la scripturile încărcate dinamic (puteți verifica hashurile manual, dar necesită cod personalizat).

SRI cuplează resursa la o anumită versiune. Dacă doriți „cea mai recentă versiune minoră” cu actualizări automate pentru remedierea erorilor, SRI nu se potrivește - fiecare modificare a resursei necesită actualizarea hash-ului. Alegerea este:

Pin la o anumită versiune cu SRI pentru detectarea falsificării
Utilizați surse de actualizare automată fără SRI și aveți încredere în furnizor

Pentru site-uri cu valoare mare, fixarea versiunii cu SRI este cea mai sigură implicită. Pentru site-urile în care corecția automată de securitate a bibliotecii contează mai mult decât detectarea falsificării (rar), compromisul merge în sens invers.

SRI și CSP împreună

SRI se asociază în mod natural cu Politica de securitate a conținutului. CSP poate specifica require-sri-pentru script style, ceea ce face ca browserul să refuze să încarce orice script sau foaie de stil fără un atribut de integritate. Acest lucru forțează utilizarea SRI la nivel de politică, prevenind omiterea accidentală.

Combinația — CSP + SRI + restricții de origine adecvate — este rețeta modernă pentru pagini web întărite. cdnjs, unpkg toate oferă hash-uri SRI pentru bibliotecile găzduite). Bariera principală în calea adoptării este complexitatea operațională:

Efiecare versiune de bibliotecă are propriul hash
Actualizarea unei biblioteci înseamnă generarea unui nou hash și actualizarea fiecărei pagini care face referire la acesta
Conductele de construcție trebuie să includă generarea hash-ului pentru auto-auto-producție. build-urile în care modificările pachetului JS per implementare necesită hashing SRI automat în pasul de construire

Cadrele majore (webpack, Vite, parcel, esbuild) includ plugin-uri SRI pentru a gestiona hashing-ul în timpul construirii. Pentru aplicațiile tipice, este o sarcină de configurare unică.

SRI în 2026

Funcția este acum linia de bază pentru site-urile conștiente de securitate. Decalajul rămas este că unele biblioteci populare sunt încărcate de la multe CDN-uri cu variante de versiune; instrumentele de urmărire și propagare a actualizărilor hash s-au îmbunătățit, dar necesită totuși atenție.

Pentru utilizatori, SRI este activ în tăcere pe multe site-uri pe care le vizitați zilnic. Browserul gestionează automat verificarea. O observați doar atunci când ceva se defectează - de obicei pentru că un hash s-a desincronizat după o actualizare a bibliotecii.

Întrebări frecvente

De ce este necesar SRI dacă folosesc deja HTTPS?: HTTPS protejează scriptul în tranzit între CDN și browser. Nu protejează împotriva compromisului CDN-ului în sine. CDN-ul care vă oferă un script rău intenționat printr-o conexiune TLS perfect validă este exact ceea ce SRI se apără.
Trebuie să specific SRI pe fiecare script?: Pentru scripturile externe, da — acolo este valoarea. Scripturile auto-găzduite pe propria ta origine nu beneficiază la fel de mult de SRI (dacă originea ta este compromisă, și pagina în sine). Cele mai multe configurații moderne aplică SRI resurselor găzduite de CDN.
Ce se întâmplă dacă biblioteca mea se actualizează frecvent?: Blocați o anumită versiune și actualizați împreună versiunea + hash. Actualizarea automată la „cele mai recente” este în contradicție cu SRI. Pentru majoritatea site-urilor de producție, versiunile fixate sunt oricum alegerea potrivită - actualizările automate ale dependențelor au cauzat incidente reale de producție.
Pot atacatorii să ocolească SRI?: Nu la nivel de protocol - matematica este solidă. Ocolirile practice provin din configurarea greșită: lipsa atributului de origine încrucișată (determină deschiderea eșuată în unele scenarii) sau atacatorul care controlează pagina în sine (caz în care nu trebuie să ocolească SRI; îl elimină).
Ar trebui să folosesc SHA-256, SHA-384 sau SHA-512?: Browserele acceptă toate trei. SHA-384 este alegerea comună - rezistență la coliziune puțin mai puternică decât SHA-256, dar mai scurtă decât SHA-512. Securitatea practică este comparabilă; alege unul și folosește-l în mod constant.