CSP-generator — Content Security Policy, med markerade vassa kanter
CSP-generator
Markera direktiven och källorna, så sätter den här sidan ihop en korrekt enradig Content-Security-Policy för svarsheadern eller <meta>-taggen — plus de noter som spelar roll: vilka direktiv som aldrig faller tillbaka till default-src, när en hash eller nonce tyst åsidosätter unsafe-inline, och vad strict-dynamic stänger av. En inbyggd SHA-256/384/512-hashgenerator gör inline-skript och -stilar till 'sha256-…'-källor. Allt körs i webbläsaren; ingenting laddas upp.
Hämtningsdirektiv — varifrån innehåll får komma
Omarkerade direktiv finns helt enkelt inte med i policyn; en markering utan valda källor ignoreras. 'none' avbryter de andra rutorna på sin rad. Rutan extra källor tar en kommaseparerad lista: värdnamn (cdn.example.com), scheman (https:), hashar och nonces med eller utan citattecken.
direktiv
'self'
'none'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
data:
blob:
extra källor
Dokumentdirektiv — vad sidan själv får göra
Dessa fyra faller inte tillbaka till default-src: att utelämna dem betyder “ingen begränsning”, så en fullständig policy anger dem uttryckligen.
direktiv
'self'
'none'
extra källor
Omkopplare, nonce och rapportering
skript-nonce
report-uri
report-to
Policy
Inget byggt ännu. Markera några källor och tryck på Bygg policy, eller läs in exemplet OWASP-baslinjen.
Hashgenerator för inline-skript och -stilar
Klistra in exakt innehållet mellan <script> och </script> (eller stilblocket) — byte för byte, utan inledande eller avslutande radbrytning — och välj en algoritm. Resultatet är 'sha256-…'-källan som CSP 3 förväntar sig.
Hash-utdata visas här.
Distribuera som header, inte som metatagg, när det går. Svarsheadern är den fullständiga CSP:n: frame-ancestors, report-uri och report-to fungerar bara där, och en header tillämpas innan första byten HTML tolkas. Metataggen är reservlösningen för statiska filer utan serverkonfiguration. Kontrollera vilka headers webbplatsen faktiskt skickar med kontrollen av säkerhetsheaders, och plocka isär råa svarsblock i HTTP-headertolkaren.
Självtest Kör byggaren igen mot fasta tillstånd: källornas ordning, den ömsesidiga uteslutningen av 'none', OWASP-baslinjesträngen, citattecken för nonce och hash, noterna om att base-uri / form-action / frame-ancestors saknar reservlösning, unsafe-inline åsidosatt av nonce eller hash, noter om strict-dynamic, headernamn för Report-Only, undantag för metataggar, hashgeneratorn mot oberoende beräknade SHA-vektorer samt de negativa vägarna. Ingenting skickas någonstans.
Vad är en Content Security Policy?
I en mening: en CSP är en vitlista som servern skickar tillsammans med en sida och som talar om för webbläsaren exakt varifrån skript, stilar, bilder och anslutningar får komma — så även om en angripare injicerar HTML misslyckas det injicerade skriptet att läsas in, eftersom dess källa inte står på listan.
vad sidan själv får göra (bäddas in, skickar formulär till, löser relativa URL:er mot)
nej — var och en måste anges uttryckligen
Rapportering och övrigt
report-uri, report-to, upgrade-insecure-requests
vart överträdelserapporter skickas, och uppgradering av gamla URL:er
nej (de är inte hämtningsdirektiv)
De vassaste kanterna, ett stycke vardera
'unsafe-inline' kontra hashar och nonces. Om ett direktiv innehåller en nonce eller någon hash-källa säger CSP 3 att 'unsafe-inline'ignoreras — det finns kvar enbart för mycket gamla webbläsare. Därför betyder “vi lade till en nonce och behöll unsafe-inline för säkerhets skull” i praktiken att moderna webbläsare tillämpar nonce:n. Generatorn flaggar kombinationen så att det blir ett beslut, inte en olycka.
strict-dynamic stänger av tillåtelselistan. Med strict-dynamic i script-src ignoreras värdkällor, scheman, 'self', 'unsafe-inline' och data: för skript; bara nonces och hashar spelar roll, och skript som de laddar får ladda ytterligare skript. Det är det moderna sättet att köra laddarskript — men det gör resten av script-src-listan till dekor.
Metataggar är andra klass.frame-ancestors, report-uri och report-to ignoreras i <meta http-equiv>. Generatorn visar vilka delar av policyn som tyst inte skulle tillämpas.
Vanliga misstag
Att börja med default-src * och en lång lista undantag. Arbeta åt andra hållet: en snäv default-src 'self', och vidga sedan bara de direktiv som behöver vidgas. Snäva policyer misslyckas högljutt under testning; vida policyer misslyckas tyst för alltid.
Att leverera script-src 'unsafe-inline' 'unsafe-eval' och anse saken klar. Den policyn blockerar nästan inget som en XSS-attack vill göra. Sätt nonce eller hash på skripten, lägg till strict-dynamic och håll report-only igång i produktion för att fånga regressioner.
Att glömma att default-src inte täcker allt.base-uri, form-action, frame-ancestors och sandbox har ingen reservlösning — det mest omtalade hålet i verkliga CSP-införanden.
Att testa i enforce-läge först. Kör i Report-Only med en insamlare i en vecka, läs rapporterna och växla sedan till tvingande läge. En policy som bryter kassan är värre än ingen policy alls.
Att hasha blanksteg olika. En hash täcker de exakta byten i det inline-blocket; ett “hjälpsamt” byggsteg som trimmar avslutande radbrytningar ändrar varje hash. Generera hashar från det som levereras, inte från källkoden.
Vanliga frågor
Behöver jag default-src om jag listar varje direktiv? Nej, men att behålla den som golv är god hygien: nya hämtningsdirektiv i framtida webbläsare får då baslinjen som standard i stället för “tillåtet”.
Vad gör upgrade-insecure-requests egentligen? Det säger åt webbläsaren att skriva om varje http://-URL som sidan skulle läsa in — bilder, stilar, hämtningar — till https:// innan den begärs. Det är ett migreringsverktyg; slutläget är sidor utan någon http://-URL alls.
Nonce eller hash? Nonce när man kontrollerar serversvaret (ett slumpvärde per svar, både i headern och i varje skripttagg). Hash när HTML:en är statisk eller cachad. Aldrig en statisk nonce — en nonce som inte ändras är bara unsafe-inline med extra steg.
Varför levereras policyn men överträdelserna kommer inte fram? Kontrollera om policyn är i Report-Only (endast rapporter), om report-uri pekar på en insamlare som accepterar POST, och om man även har satt upp Reporting-Endpoints / Report-To-mekanismen som det moderna direktivet report-to kräver.
Ersätter en CSP andra skydd? Nej. Det är ett lager: fortsätt escapa utdata, håll cookies bakom HttpOnly och Secure, behåll HSTS. Kontrollen av säkerhetsheaders på den här webbplatsen betygsätter hela uppsättningen.
