Gepubliceerd: 17 november 2025
Vanaf Chrome 141 kunt u deelnemen aan de Origin Trial om de nieuwe functies voor Content Security Policy (CSP) te testen die Chrome introduceert. Deze functies helpen websites zich te beschermen tegen XSS door bekende bronnen van JavaScript beter op de whitelist te plaatsen. Het op de whitelist plaatsen van bekende JavaScript-bronnen en het blokkeren van alle andere bronnen is een effectieve manier om XSS te voorkomen. JavaScript dat door een aanvaller is ingevoegd, komt niet op de whitelist te staan en wordt daarom geblokkeerd.
Zonder deze functies is het lastig om een "strikte" CSP te hebben die alle JavaScript-bronnen op een whitelist plaatst zonder een nonce-communicatiemechanisme tussen de scripthost en de site, of zonder de volledige hash van het script vooraf te kennen. Beide methoden zijn lastig te implementeren als het script regelmatig verandert en wordt gehost door een vertrouwde, maar onafhankelijke derde partij. Bovendien vereist CSP momenteel dat u eval voor alle scripts op de whitelist plaatst als een script eval moet gebruiken, wat de CSP veel zwakker maakt.
We proberen deze lacune op te vullen door een sterker mechanisme te bieden voor URL-gebaseerde allowlisting van scripts in script-src , en een mechanisme voor het allowlisten van aanroepen naar eval. U kunt het bestaande hashmechanisme in script-src gebruiken om URL's van specifieke scripts en JavaScript die aan eval (en andere eval-achtige functies) worden doorgegeven, op de allowlist te zetten. Hoewel URL-gebaseerde allowlisting misschien niet zo strikt is als een integriteitsgebaseerde CSP, zou dit mechanisme een grote verbetering moeten zijn ten opzichte van de bestaande hostname-allowlist.
Wij zijn van mening dat dit een eenvoudiger te implementeren CSP-beleid oplevert dat XSS nog steeds robuust beperkt door niet-toegestane inline- en evaluatiescripts te blokkeren. Deze nieuwe functies zijn zorgvuldig ontworpen en geïmplementeerd om sites in staat te stellen een beleid in te stellen dat betere beveiliging biedt in browsers die de nieuwe functionaliteit ondersteunen, zonder dat dit leidt tot problemen of een verslechtering van de beveiliging in browsers die dat niet doen, en zonder dat er user-agent sniffing hoeft te worden uitgevoerd.
Gebruiksscenario's
Specifieke URL's op de toegestane lijst zetten voor gebruik met script-src
Sites die specifieke scripts op de whitelist willen zetten voor gebruik met script-src, hebben momenteel twee opties: de inhoud van de scripts op de whitelist zetten via Subresource Integrity (SRI) of host-source gebruiken om hostnamen op de whitelist te zetten. SRI is vaak niet praktisch voor scripts die vaak veranderen (bijvoorbeeld analysescripts). Het opgeven van host-source wordt genegeerd wanneer strict-dynamic ook is ingesteld en biedt geen uitgebreide bescherming, omdat het geen URL-parameters bevat. Deze wijziging maakt het mogelijk om scripts op de whitelist te zetten met behulp van een hash van hun (volledige) URL, met ondersteuning voor zowel dynamische scripts als configuraties die strict-dynamic gebruiken.
Toestaanlijstspecifieke scripts voor gebruik met eval- of eval-achtige functies
Sommige sites vereisen het gebruik van eval of eval-achtige functies (het doorgeven van code als tekenreeksliteralen in setTimeout , setInterval en setImmediate ). Voor deze sites is unsafe-eval de enige beschikbare CSP-optie, waarmee alle aanroepen van eval worden ingeschakeld. We voegen een mechanisme toe om specifieke invoer voor eval op de whitelist te plaatsen. Dit nieuwe mechanisme maakt het mogelijk om de specifieke benodigde scripts nauwkeurig op de whitelist te plaatsen door de inhoud van het script rechtstreeks te hashen, in plaats van gedwongen te worden een te brede unsafe-eval CSP te gebruiken.
Aan de slag
Als u de ondersteuning voor script- en eval-hashing wilt uitproberen, kunt u deelnemen aan de URL- en eval-hashes in CSP script-src origin trial , beschikbaar voor Chrome 141 tot en met 144.
Hashes toevoegen aan script-src
URL's worden op de whitelist geplaatst door een waarde toe te voegen aan de script-src CSP-richtlijn in de vorm van url-<hash-algorithm>-<script-url-hash> . Dit staat toe dat alle content die die URL aanbiedt, ongeacht de content, wordt uitgevoerd. De hash hoeft alleen de initiële URL (de URL die op de pagina staat) te bevatten, niet een URL waarnaar die URL doorverwijst. Zowel absolute als relatieve URL's worden ondersteund.
De volgende CSP-header zal bijvoorbeeld het script dat wordt geserveerd op https://example.com/example.js op de whitelist plaatsen:
Content-Security-Policy: script-src 'sha256-u2cYltM/2wbvoRR0jMZ57KmFdVqqdPYa6GtdykFwBGc=';
waarbij 'sha256-u2cYltM/2wbvoRR0jMZ57KmFdVqqdPYa6GtdykFwBGc=' de sha256-hash is van ' https://example.com/example.js '.
Scripts die via eval of new Function worden geëvalueerd, kunnen op de whitelist worden geplaatst door eval-<hash-algorithm>-<script-contents-hash> toe te voegen aan script src. De volgende CSP-header zal bijvoorbeeld de string alert("hello world") die aan eval() wordt doorgegeven, op de whitelist plaatsen:
Content-Security-Policy: script-src 'eval-sha256-4vpsisrBP00v+tF/SsQ3RXWWYF28JSvTpR9D/wrxn/0=';
waarbij 'eval-sha256-4vpsisrBP00v+tF/SsQ3RXWWYF28JSvTpR9D/wrxn/0=' de sha256-hash is van alert("hello world") .
Om de bootstrap-adoptie te bevorderen, worden hashes voor zowel URL's als eval , wanneer een site zich aanmeldt voor de origin trial, afgedrukt in de DevTools-console en opgenomen in CSP-rapporten. Dit betekent dat een strikt, maar report-only beleid kan worden gebruikt om alle hashes te inventariseren die nodig zijn voor toelating op de whitelist.
Behoud achterwaartse compatibiliteit
Om de implementatie van dit beleid mogelijk te maken voordat alle browsers ondersteuning hebben toegevoegd, kunnen URL-hashes na hostgebaseerde toestemmingslijsten worden weergegeven. Browsers die de nieuwe hashtypen begrijpen, negeren voorafgaande hostgebaseerde toestemmingslijsten, terwijl browsers die de nieuwe hashtypen niet begrijpen, de hostgebaseerde toestemmingslijst nog steeds handhaven. Hierdoor kunnen sites beide instellen met behulp van het strengere beleid in browsers die dit ondersteunen, zonder het risico te lopen dat het beleid in browsers die dit niet ondersteunen, wordt verbroken, zoals in het volgende voorbeeld wordt getoond.
Content-Security-Policy: script-src 'https:' 'url-sha256-u2cYltM/2wbvoRR0jMZ57KmFdVqqdPYa6GtdykFwBGc='
We hebben ook strict-dynamic-url geïntroduceerd, een equivalent van strict-dynamic dat alleen van toepassing is wanneer URL-hashes zijn ingesteld. Omdat strict-dynamic ervoor zorgt dat hostgebaseerde allowlists worden genegeerd, kan een site die een specifieke hash op de allowlist wil zetten en strict dynamic hierop wil toepassen, een beleid gebruiken zoals:
Content-Security-Policy: https: 'strict-dynamic-url' 'url-sha256-u2cYltM/2wbvoRR0jMZ57KmFdVqqdPYa6GtdykFwBGc='
In dit voorbeeld zullen browsers die nog geen hashes ondersteunen, alleen https: afdwingen. unsafe-eval wordt eveneens genegeerd door browsers die eval-hashes ondersteunen wanneer er eval-hashes aanwezig zijn. Het volgende beleid wordt bijvoorbeeld geëvalueerd als unsafe-eval . Dit schakelt alle eval() gebruik in op browsers die nog geen eval-hashes ondersteunen, terwijl de eval() van alert("hello world") alleen is toegestaan in browsers die eval-hashes ondersteunen.
Content-Security-Policy: script-src "unsafe-eval" "'eval-sha256-4vpsisrBP00v+tF/SsQ3RXWWYF28JSvTpR9D/wrxn/0='"
Feedback delen
We zijn geïnteresseerd in feedback van ontwikkelaars over deze uitbreidingen van script-src . Plaats eventuele opmerkingen als een probleem in de explainer op GitHub .