CSP-generator — Content Security Policy, bygget med de skarpe kanter markeret
CSP-generator
Markér direktiverne og kilderne, og denne side sammensætter en korrekt enkeltlinjes Content-Security-Policy til svarheaderen eller et <meta>-tag — samt de noter, der betyder noget: hvilke direktiver der aldrig falder tilbage til default-src, hvornår en hash eller nonce stille og roligt tilsidesætter unsafe-inline, og hvad strict-dynamic slår fra. En indbygget SHA-256/384/512-hashgenerator gør inline-scripts og -styles til 'sha256-…'-kilder. Alt kører i browseren; intet uploades.
Fetch-direktiver — hvor indhold må komme fra
Direktiver, der ikke er markeret, er blot fraværende i politikken; et flueben uden valgte kilder ignoreres. 'none' annullerer de andre felter i sin række. Feltet ekstra kilder tager en kommasepareret liste: værtsnavne (cdn.example.com), skemaer (https:), hashes og nonces med eller uden anførselstegn.
direktiv
'self'
'none'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
data:
blob:
ekstra kilder
Dokumentdirektiver — hvad siden selv må
Disse fire falder ikke tilbage til default-src: udelades de, betyder det "ingen begrænsning", så en komplet politik angiver dem eksplicit.
direktiv
'self'
'none'
ekstra kilder
Kontakter, nonce og rapportering
script-nonce
report-uri
report-to
Politik
Intet bygget endnu. Markér nogle kilder, og tryk på Byg politik, eller indlæs OWASP-basislinjeeksemplet.
Hashgenerator til inline-scripts og -styles
Indsæt det nøjagtige indhold mellem <script> og </script> (eller style-blokken) — byte for byte, uden førende eller efterstillede linjeskift — og vælg en algoritme. Resultatet er 'sha256-…'-kilden, som CSP 3 forventer.
Hash-output vises her.
Udrul som header, ikke som meta-tag, når det er muligt. Svarheaderen er den fulde CSP: frame-ancestors, report-uri og report-to virker kun dér, og en header anvendes, før den første byte af HTML er parset. Meta-tagget er reserveløsningen for statiske filer uden serverkonfiguration. Kontrollér de headers, webstedet faktisk sender, med kontrollen af sikkerhedsheadere, og analysér rå svarblokke i HTTP-headerparseren.
Selvtest Kører byggeren igen mod faste tilstande: kildernes rækkefølge, 'none'-gensidig udelukkelse, OWASP-basislinjestrengen, anførselstegn omkring nonce og hash, noter om ingen fallback for base-uri / form-action / frame-ancestors, unsafe-inline tilsidesat af nonce eller hash, noter om strict-dynamic, Report-Only-headernavne, meta-tag-udelukkelser, hashgeneratoren mod uafhængigt beregnede SHA-vektorer og negative stier. Intet sendes nogen steder.
Hvad er en Content Security Policy?
I én sætning: en CSP er en hvidliste, serveren sender med en side, som fortæller browseren præcis, hvor scripts, styles, billeder og forbindelser må komme fra — så selv hvis en angriber indsætter HTML, indlæses det indsatte script ikke, fordi dets kilde ikke står på listen.
hvad siden selv må (indlejres, sende formularer til, slå relative URL'er op mod)
nej — hver skal angives eksplicit
Rapportering og diverse
report-uri, report-to, upgrade-insecure-requests
hvor overtrædelsesrapporter sendes, og opgradering af ældre URL'er
nej (de er ikke fetch-direktiver)
De skarpeste kanter, ét afsnit hver
'unsafe-inline' vs. hashes og nonces. Hvis et direktiv indeholder en nonce eller en hash-kilde, siger CSP 3, at 'unsafe-inline'ignoreres — det bliver kun stående for gamle browsere. Derfor betyder "vi tilføjede en nonce og beholdt unsafe-inline for sikkerhed skyld", at moderne browsere håndhæver nonce'en. Generatoren markerer kombinationen, så det er en beslutning og ikke et uheld.
strict-dynamic slår tilladelseslisten fra. Med strict-dynamic i script-src ignoreres værtskilder, skemaer, 'self', 'unsafe-inline' og data: for scripts; kun nonces og hashes betyder noget, og scripts, de indlæser, må indlæse flere scripts. Det er den moderne måde at køre loader-scripts på — men det gør resten af script-src-listen dekorativ.
Meta-tags er andenrangs.frame-ancestors, report-uri og report-to ignoreres i <meta http-equiv>. Generatoren viser, hvilke dele af politikken der stille og roligt ikke gælder.
Almindelige fejl
Start med default-src * plus en lang liste af undtagelser. Arbejd den anden vej: en stram default-src 'self', og gør derefter kun de direktiver bredere, der har brug for det. Snævre politikker fejler højlydt under test; brede politikker fejler lydløst for evigt.
At udrulle script-src 'unsafe-inline' 'unsafe-eval' og så kalde det færdigt. Den politik blokerer næsten intet, et XSS-angreb vil gøre. Giv scripts en nonce eller hash, tilføj strict-dynamic, og hold report-only kørende i produktion for at fange regressioner.
At glemme, at default-src ikke dækker alt.base-uri, form-action, frame-ancestors og sandbox har ingen fallback — det mest citerede hul i reelle CSP-udrulninger.
At teste i enforce-tilstand først. Kør i Report-Only med en modtager i en uge, læs rapporterne, og skift derefter til håndhævelse. En politik, der ødelægger kassen, er værre end ingen politik.
At hashe mellemrum forskelligt. En hash dækker de nøjagtige bytes i det inline-blok; et "hjælpsomt" build-trin, der trimmer efterstillede linjeskift, ændrer hver hash. Generér hashes ud fra det, der udsendes, ikke ud fra kilden.
Ofte stillede spørgsmål
Behøver jeg default-src, hvis jeg lister alle direktiver? Nej, men det er god hygiejne at beholde den som gulv: nye fetch-direktiver i fremtidige browsere falder så tilbage til basislinjen i stedet for til "tilladt".
Hvad gør upgrade-insecure-requests egentlig? Den fortæller browseren at omskrive hver http://-URL, siden ellers ville indlæse — billeder, styles, fetch — til https://, før den anmodes om. Det er et migreringsværktøj; slutresultatet er sider uden nogen http://-URL overhovedet.
Nonce eller hash? Nonce, når serverens svar kontrolleres (en tilfældig værdi pr. svar, både i headeren og i hvert script-tag). Hash, når HTML'en er statisk eller cachet. Aldrig en statisk nonce — en nonce, der ikke ændrer sig, er blot unsafe-inline med ekstra trin.
Hvorfor leveres politikken, men overtrædelser ankommer ikke? Tjek om der er tale om Report-Only (kun rapporter), om report-uri peger på en modtager, der accepterer POST, og om Reporting-Endpoints/Report-To-mekanismen også er sat op, som det moderne report-to-direktiv kræver.
Erstatter en CSP andre beskyttelser? Nej. Den er ét lag: bliv ved med at escape output, hold cookies bag HttpOnly og Secure, behold HSTS. Kontrollen af sikkerhedsheadere på dette websted vurderer hele sættet.
