CSP-generator (Content Security Policy)

Q: Är 'unsafe-inline' i style-src ett problem?

Det är mindre farligt än i script src och mycket vanligt, eftersom många bibliotek sätter inbäddade stilar. Inskjuten CSS kan ändå förvanska en sida eller läcka data, så granskningen listar det med låg allvarlighetsgrad.

Q: Är värdarna för Google Analytics kompletta?

De är exempel från Googles CSP vägledning för Google taggen. Google justerar dem över tid och regionala domäner kan behövas; kontrollera Googles aktuella dokumentation och ta bort det du inte använder. Det inbäddade gtag.js utdraget behöver också en nonce eller hash.

Q: Varför blockerar min policy mina egna inbäddade skript?

När script src är satt utan 'unsafe inline' blockeras varje inbäddat <script och varje onclick= attribut. Flytta koden till en fil, eller lägg till en nonce eller en hash.

Q: Kan jag ha flera policyer?

Ja: om en sida får flera CSP headers måste en resurs uppfylla alla. Klistra in en policy i taget i utvärderingen.

Skapa en Content-Security-Policy som header, meta-tagg och Report-Only-version med förinställningar, nonces och SHA-256-hashar, och granska en befintlig policy.

Utgå från en förinställning

Google-värdarna är exempel hämtade från Googles CSP-vägledning för Google-taggen. Google ändrar dem då och då: kontrollera den aktuella dokumentationen och ta bort det du inte använder.

Direktiv

Källor avgränsade med mellanslag. Lämna ett fält tomt för att utelämna direktivet (hämtningsdirektiv faller då tillbaka på default-src).

default-srcReserv för övriga hämtningsdirektiv script-srcJavaScript style-srcStilmallar och inbäddade stilar img-srcBilder och favicons connect-srcfetch, XHR, WebSocket, EventSource font-srcWebbtypsnitt frame-srcSidor du bäddar in i iframes worker-srcWeb workers och service workers media-srcLjud och video object-srcPlugin (<object>, <embed>): använd 'none' base-uriTillåtna värden för <base href> form-actionDit formulär får skickas frame-ancestorsVem som får bädda in din sida (clickjacking)

Snabbtillägg Direktiv

En nonce måste vara ett nytt slumpvärde i varje svar, skapat av din server och upprepat i varje <script nonce="…">. En fast nonce skyddar ingenting.

Hasha ett inbäddat skript eller en inbäddad stil Inbäddad kod, eller HTML med <script>/<style>-element

Lägg till i

Hashen gäller exakt texten mellan taggarna, inklusive mellanslag och radbrytningar: varje ändring kräver en ny hash. Inbäddade händelsehanterare (onclick=…) kräver dessutom 'unsafe-hashes'.

upgrade-insecure-requests (ladda http://-resurser över https://)

Överträdelserapporter Webbadress för rapportmottagare (valfritt) Gruppnamn för report-to

Lägger till report-uri (äldre webbläsare) och report-to med en Reporting-Endpoints-header.

HTTP-header

Report-Only-header (testa utan att blockera)

HTML-<meta>-tagg

I en <meta>-tagg ignorerar webbläsare frame-ancestors, report-uri, report-to och sandbox, och Report-Only stöds inte. Lägg taggen högst upp i <head>: den gäller bara innehåll som kommer efter den.

Granskning av policyn

Utvärdera en befintlig policy

Klistra in en policy, en header-rad eller en <meta>-tagg

Så bygger du en policy

Välj en startpunkt under Utgå från en förinställning: Strikt (nonce + strict-dynamic), Låst statisk webbplats, Typisk webbplats eller Typisk + Google Analytics / Ads. Redigeraren öppnas med förinställningen för en typisk webbplats.
Justera Direktiv. Varje fält tar källor avgränsade med mellanslag; ett tomt fält utelämnar direktivet.
Använd Snabbtillägg för att lägga till ett nyckelord i det valda Direktiv: 'self', 'none', 'unsafe-inline', 'strict-dynamic', https:, data: med flera. Lägg till en nonce infogar en slumpmässig 128-bitars nonce.
Om du vill tillåta ett visst inbäddat skript utan 'unsafe-inline' klistrar du in det (eller HTML-koden runt det) under Hasha ett inbäddat skript eller en inbäddad stil och klickar på Beräkna SHA-256 och lägg till.
Kryssa i upgrade-insecure-requests om några gamla webbadresser fortfarande använder http://, och fyll vid behov i Webbadress för rapportmottagare (valfritt).
Kopiera HTTP-header, Report-Only-header eller HTML--tagg. Granskning av policyn uppdateras medan du skriver.

Vill du granska en policy du redan har klistrar du in den under Utvärdera en befintlig policy och klickar på Utvärdera policy. Läs in i redigeraren kopierar in den i fälten. Allt körs i din webbläsare: inget du skriver in skickas till en server.

Vad en Content Security Policy gör

En CSP talar om för webbläsaren från vilka ursprung en sida får ladda skript, stilar, bilder, typsnitt, ramar och anslutningar. Dess viktigaste uppgift är att begränsa skriptinjektion mellan webbplatser (XSS): även om en angripare lyckas skjuta in kod på din sida hindrar en bra policy det inskjutna skriptet från att köras. Den styr också vem som får bädda in din sida (frame-ancestors), vart formulär får skickas (form-action) och vad <base> får peka på (base-uri).

Hämtningsdirektiv som img-src eller font-src faller tillbaka på default-src när de saknas. base-uri, form-action och frame-ancestors faller inte tillbaka, och därför ber granskningen uttryckligen om dem.

Nonces, hashar och strict-dynamic

Att tillåta värdar (script-src https://cdn.example.com) ser säkert ut men går ofta att kringgå: stora domäner har JSONP-slutpunkter och gamla bibliotek som en angripare kan återanvända. Det upplägg som webbläsarnas säkerhetsteam rekommenderar är en strikt CSP: varje legitimt <script> har en nonce som servern skapar för varje svar, eller tillåts via sin hash, och 'strict-dynamic' låter dessa betrodda skript ladda de skript de behöver. I det upplägget är https: och 'unsafe-inline' bara reserver för mycket gamla webbläsare; moderna ignorerar dem.

En nonce fungerar bara om den ändras i varje svar och är oförutsägbar. Den som Lägg till en nonce infogar är ett exempel: din server eller ditt ramverk måste skapa sin egen. En hash gäller exakt de byte som den inbäddade koden består av, så om du formaterar om skriptet behövs en ny hash.

Header, Report-Only och meta-tagg

Skicka policyn som en HTTP-header när du kan. Inför den först som Content-Security-Policy-Report-Only: webbläsare rapporterar överträdelser (till konsolen, och till din mottagare om du angett en) utan att blockera något, så att du kan åtgärda dina sidor innan policyn börjar gälla på riktigt. Rapportinställningarna lägger till report-uri för äldre webbläsare och report-to med en Reporting-Endpoints-header.

Varianten med <meta http-equiv> är praktisk på statiska webbhotell, men webbläsare ignorerar frame-ancestors, report-uri, report-to och sandbox i den, och det finns ingen Report-Only-meta-tagg. Verktyget tar bort de direktiven ur taggen och talar om det.

Vanliga frågor

Är 'unsafe-inline' i style-src ett problem?

Det är mindre farligt än i script-src och mycket vanligt, eftersom många bibliotek sätter inbäddade stilar. Inskjuten CSS kan ändå förvanska en sida eller läcka data, så granskningen listar det med låg allvarlighetsgrad.

Är värdarna för Google Analytics kompletta?

De är exempel från Googles CSP-vägledning för Google-taggen. Google justerar dem över tid och regionala domäner kan behövas; kontrollera Googles aktuella dokumentation och ta bort det du inte använder. Det inbäddade gtag.js-utdraget behöver också en nonce eller hash.

Varför blockerar min policy mina egna inbäddade skript?

När script-src är satt utan 'unsafe-inline' blockeras varje inbäddat <script> och varje onclick=-attribut. Flytta koden till en fil, eller lägg till en nonce eller en hash.

Ersätter en CSP att man hanterar användarindata korrekt?

Nej. En CSP är en andra försvarslinje. Fortsätt att koda utdata och validera indata; policyn begränsar skadan när något ändå slinker igenom.

Kan jag ha flera policyer?

Ja: om en sida får flera CSP-headers måste en resurs uppfylla alla. Klistra in en policy i taget i utvärderingen.