Utilia

SRI-hashgenerator

Generera SRI-hashar (Subresource Integrity) med sha384 för en JavaScript- eller CSS-fil och kopiera färdiga integrity- och crossorigin-attribut.

Klistra in filens innehåll eller öppna själva filen: verktyget laddar inte ner URL:er. Att läsa ett skript från en annan webbplats skulle kräva att den servern tillåter det (CORS) eller att en egen server hämtar det åt dig, och inget du hashar här lämnar någonsin din webbläsare. Hasha exakt den fil du kommer att leverera.

Hasha

Texten hashas som UTF-8. Webbläsare gör om Windows-radslut (CRLF) till LF i inklistrad text, och en enda ändrad byte förstör hashen: öppna själva filen om du är osäker.

Algoritmer

URL:en skrivs bara in i kodsnutten, den anropas aldrig. Lämna fältet tomt för att använda filnamnet.

Så genererar du en SRI-hash

  1. Under Hasha väljer du Inklistrad kod eller Filer.
  2. Klistra in det exakta innehållet i skriptet eller stilmallen i Innehåll i skript eller stilmall och klicka på Generera SRI-hash, eller släpp en eller flera .js- och .css-filer i släppytan. Hasharna uppdateras medan du skriver.
  3. Låt SHA-384 (rekommenderas) vara ikryssad, eller lägg till SHA-256 och SHA-512. Varje ikryssad algoritm lägger till ett element i värdet.
  4. Välj Tagg (automatiskt utifrån filnamnet, <script>, <script type="module"> eller <link rel="stylesheet">), skriv in Resursens URL för kodsnutten (valfritt) och välj läge för crossorigin.
  5. Kopiera integrity-värde eller hela taggen.
  6. Vill du kontrollera en tagg som du redan använder klistrar du in värdet eller hela taggen i Kontrollera ett befintligt integrity-värde (valfritt).

Vad Subresource Integrity gör

När en sida läser in ett skript från ett CDN litar webbläsaren på vad servern än skickar tillbaka. Om CDN:et blir komprometterat eller filen ändras körs den ändrade koden med full åtkomst till din sida. Subresource Integrity (W3C SRI) täpper till det hålet: du publicerar filens förväntade hash i attributet integrity, webbläsaren hashar det den laddar ner och vägrar att köra skriptet eller tillämpa stilmallen om de två skiljer sig åt.

<script src="https://cdn.example.com/lib.min.js"
        integrity="sha384-H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO"
        crossorigin="anonymous"></script>

Värdet består av algoritmens namn, ett bindestreck och den Base64-kodade hashen av filens byte. Exemplet ovan är hashen av alert('Hello, world.'); från SRI-specifikationen. När flera hashar anges tittar webbläsare bara på den starkaste algoritmen som finns och godtar filen om någon hash med den algoritmen stämmer. Så kan en webbplats ange två versioner av en fil under en utrullning.

Därför krävs crossorigin

För en fil från ett annat ursprung kan webbläsaren bara kontrollera integriteten om svaret hämtas i CORS-läge. Taggen behöver därför ett crossorigin-attribut, och servern måste svara med huvudet Access-Control-Allow-Origin. Använd anonymous (utan cookies) för publika CDN:er. use-credentials är till för sällsynta privata resurser. Utan CORS blockerar webbläsaren filen i stället för att läsa in den okontrollerad.

Därför hämtar verktyget inga URL:er

Verktyget hashar bara kod som du klistrar in eller filer som du öppnar. Att ladda ner ett skript från dess URL inne på sidan skulle bara fungera när servern tillåter läsning från andra ursprung, och att gå runt det skulle kräva en server som hämtar filen åt dig – en server som då också skulle se vad du hashar. Allt här körs i din webbläsare. Det enklaste är att ladda ner exakt den fil du kommer att referera till (samma version och samma minifierade bygge) och öppna den här.

Vanliga frågor

Vilken algoritm ska jag använda?

SHA-384 är det vanliga valet och det de flesta CDN:er publicerar. SHA-256 och SHA-512 stöds också av alla moderna webbläsare. MD5 och SHA-1 är inte tillåtna i SRI.

Hashen är rätt men webbläsaren blockerar ändå filen. Varför?

Kontrollera att servern skickar Access-Control-Allow-Origin och att taggen har crossorigin. Se också till att CDN:et levererar exakt samma byte: en annan version, en automatisk minifierare eller en saknad radbrytning i slutet ändrar alla hashen.

Varför ger min inklistrade kod en annan hash än filen?

Webbläsare gör om Windows-radslut (CRLF) till LF i textfält, och en redigerare kan lägga till eller ta bort en byte order mark (BOM) eller en avslutande radbrytning. Öppna själva filen för att hasha exakt dess byte.

Behöver jag SRI för filer på min egen domän?

SRI skyddar mot ändringar som görs efter att du räknade ut hashen, så det är viktigast för tredjepartsvärdar. För dina egna filer är det oftast enklare med en bundler som genererar hasharna vid byggtillfället.

Fungerar SRI för bilder eller typsnitt?

Attributet integrity stöds på <script> och <link rel="stylesheet"> (och på <link rel="preload"> eller modulepreload för dessa). Bilder och typsnitt kan inte använda det.