Defaults.Exposed › Rettelser › Content-Security-Policy (CSP)

Sådan retter du Content-Security-Policy (CSP)

En Content Security Policy er en sikkerhedsregel din hjemmeside giver enhver besøgendes browser og fortæller den præcis, hvilken kode der har tilladelse til at køre. Uden en — hvis noget ondsindet nogensinde lander på en side — via et kommentarfelt, et hacket plugin eller et tredjepartsscript — vil browseren køre det frit, inklusive kode der stille skimmer dine kunders kortnumre og adgangskoder, mens de taster, med låsen stadig synlig.

Det korte svar for din virksomhed: Manipuleres din side nogensinde, kan ondsindet kode læse dine kunders betalingskort- og loginoplysninger direkte fra din checkout, mens alt ser fuldstændig normalt ud — og efterlader dig med chargebacks, svindelkrav, et reportabelt databrud og et tjek-fejl som større klienters sikkerhedsteam bruger til at stalle eller dræbe en aftale.

Hvad dette kan koste dig

Skjult kode glider ind på én af dine sider og kopierer stille hvert kortnummer og adgangskode dine kunder indtaster ved checkout og sender det til en angriber, mens din side ser fuldstændig normal ud — du finder kun ud af det, da svindelklagerne ankommer.
En svindler planter en falsk 'betal her'-formular på din rigtige hjemmeside der opsnappe betalinger til sin egen konto; kunder tror, de betalte dig, bebrejder dig, når varerne aldrig ankommer, og kræver pengene tilbage.
Et større klients sikkerhedsteam scanner din side, ser at denne grundlæggende beskyttelse er slået fra, og flagger det — staller eller mister dig kontrakten til det kan bevises, at det er fikset.
Et brud sporet til et manglende standardsikkerhedstiltag bliver en reportabel hændelse: regulatorspørgsmål, kundenotifikationer og et omdømmeskud der koster langt mere end den gratis rettelse.

Hvorfor det betyder noget. Låsen beviser, at forbindelsen til din side er privat, men den gør intet for at kontrollere, hvilken kode der kører, når en besøgende er på siden. En Content Security Policy er det sikkerhedstiltag der gør det — den siger til browsere om at ignorere ethvert script der ikke kom fra en kilde du stoler på, så ét manipuleret felt, annonce eller plugin ikke kan forvandles til et redskab til at stjæle dine kunders penge og data. Det er et scoret tjek på dit scorecard, der er reelle point værd, og et af de første ting en professionel sikkerhedsgennemgang kigger efter.

Hvad dette er på klart dansk

Når nogen besøger din hjemmeside, downloader deres browser din side og kører uanset hvilken kode der er på den — scripts der lader menuer droppe ned, knapper virke, betalingsformularer sende og så videre. Som standard stoler browseren på alt det. Den har ingen måde at vide, hvilken kode der virkelig er din, og hvilken der er sneget ind af nogen anden.

En Content Security Policy (ofte forkortet CSP) er en kort liste af regler din hjemmeside vedhæfter enhver side og siger til browseren: “kør kun kode fra disse kilder jeg har godkendt, og nægt alt andet.” Det er forskellen på en natklub der lukker alle ind og en med en gæsteliste ved døren.

Grunden til at dette tæller så meget, er at hjemmesider konstant manipuleres med — ikke altid ved at hacke din server, men via de bagdøre de fleste sider efterlader åbne: et kommentarfelt, en søgeboks, et forældet plugin, et tredjepartsscript til annoncer eller analytics, eller en chat-widget. Får en angriber blot én linje af sin kode ind på én af dine sider, kører browseren den, som om den var din. Derfra kan den læse alt dine kunder taster — kortnumre, adgangskoder, adresser — og stille sende det et andet sted hen.

Hvad dette kan koste dig

Den usynlige checkout-skimmer. En angriber lader et par linjer kode ind på din checkoutside via et sårbart plugin eller et kompromitteret tredjepart-script. Hvert kortnummer, navn og CVV dine kunder taster kopieres og sendes til angriberen i realtid. Din side ser ud og fungerer perfekt; låsen er der. Du opdager det uger senere, da din betalingsudbyder ringer om en klynge af svindelrapporter der alle sporer til din butik.
Den falske betalingsformular. En svindler injicerer en overbevisende “betal her”-boks på din rigtige hjemmeside. Kunder taster oplysningerne og stoler på dit brand; penge og data går til angriberen.
Den tabte kontrakt. Et større prospects sikkerhedsteam kører en automatiseret scanning af din side som del af leverandørs due diligence. En manglende Content Security Policy dukker straks op som et høj-alvorligheds-hul.
Det reportable brud. Når et databrud spores tilbage til et manglende, standard, gratis sikkerhedstiltag, holder det op med at være uheld og begynder at se ud som uagtsomhed.
Det kompromitterede script eller widget. Mange sider indlæser kode fra parter udenfor — annoncenetværk, skrifttyper, support-chat, analytics. Kompromitteres nogen af dem, rider den ondsindede kode direkte ind på dine sider.

Hvad det faktisk er (detaljerne)

En Content Security Policy leveres som et enkelt HTTP-svar-header — en linje din webserver sender med enhver side. Dens værdi er et sæt direktiver, der hver navngiver en indholdstype og de tilladte kilder for den. For eksempel:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

Hvad “godt” ser ud som. Vores tjek kigger ikke blot efter headerets tilstedeværelse — det læser politikken direktiv for direktiv og scorer, hvor stærk den faktisk er. En stærk politik:

Sætter en restriktiv baseline (default-src 'self') og udvider kun for de specifikke betroede tredjeparter du virkelig bruger.
Undgår smuthullerne. Den bruger ikke 'unsafe-inline' eller 'unsafe-eval' for scripts, og bruger ikke wildcard (*) eller bare schemeskilder (som https:) for scripts. Hvor inline-scripts er nødvendige, bruger den et nonce eller hash.
Låser framing ned med frame-ancestors 'self' og deaktiverer legacy-plugins med object-src 'none'.
Håndhæver, er ikke report-only. En Content-Security-Policy-Report-Only-header er kun ser; den giver nul runtime-beskyttelse.

Sådan fikser du det (gratis, ~1–2 timer)

Overrækk dette til din IT-person eller den der kører din hjemmeside — selve fikset er helt gratis. Vi opkræver kun betaling for at overvåge, at det forbliver på plads og forbliver korrekt over tid.

Start i report-only-tilstand — håndhæv ikke endnu. Tilføj et Content-Security-Policy-Report-Only-svar-header. Dette ser og logger, hvad der ville være blokeret, uden at blokere noget, så live-siden fortsætter med at fungere.
Byg politikken ud fra, hvad din side faktisk bruger. Gennemgå rapporterne for at finde enhver legitim kilde til scripts, stilarter, skrifttyper og billeder — dit eget domæne, din analytics, din betalingsudbyder, din skrifttype-host, din chat-widget.
Undgå smuthullerne der overvinder hele pointen. Styr udenom 'unsafe-inline' og 'unsafe-eval' for scripts, og undgå wildcard-kilder som * og bare schemers som https: for scripts. Brug et nonce eller hash for godkendte inline-scripts.
Lås framing og plugins ned. Tilføj frame-ancestors 'self' og object-src 'none'.
Skift fra report-only til håndhævelse. Når rapporterne er rene og siden fungerer, skift header-navnet fra Content-Security-Policy-Report-Only til Content-Security-Policy. Dette er det trin der faktisk giver beskyttelse.

Hvor du sætter headeret, afhænger af din platform:
- Cloudflare: Rules → Transform Rules → Modify Response Header → sæt Content-Security-Policy.
- Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
- Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
Tjek dit domæne igen for at bekræfte, at politikken nu vises som aktiveret og håndhævet.

Almindelige fejl

At stoppe ved report-only. Den enkeltstående mest almindelige fejl: en politik tilføjes i report-only-tilstand, alle går videre, og siden er aldrig faktisk beskyttet. Report-only blokerer ingenting.
At nå efter 'unsafe-inline' for at få det til at “bare virke.” Når politikken blokerer et legitimt inline-script, er den hurtige rettelse at tillade alle inline-scripts — men det genåbner præcis det hul politikken var ment at lukke.
At bruge et wildcard. Et bart * (eller https:) i script-src tillader scripts fra hvorsomhelst.
At glemme tredjepartskilder. At håndhæve en streng politik uden først at liste de legitime udenfor-tjenester du bruger kan bryde dele af din egen side.
At sætte det kun på forsiden. Politikken skal dække enhver side, især checkout, login og kontosider.

FAQ

Jeg er ikke teknisk — kan jeg selv klare det?

Du behøver ikke forstå detaljerne. Dette er en indstilling tilføjet af den der kører din hjemmeside eller hosting, og på tjenester som Cloudflare er det langt hen ad vejen guidet. Send dem afsnittet 'Sådan fikser du det' nedenfor. Det er gratis; den ene forsigtighed er, at det bør rulles ud omhyggeligt i en kun-se-tilstand først, så det ikke ved et uheld blokerer dele af din egen side — hvilket er præcis, hvad trinnene dækker.

Jeg har allerede låsen og et SSL-certifikat — er min side ikke sikker?

Låsen sikrer leveringen af din side; den patruljerer ikke, hvad der kører inde i den. Ender ondsindet kode på en side — via et hacket plugin, et kompromitteret script eller et injiceret felt — stopper låsen det ikke fra at stjæle data. En Content Security Policy er det lag der begrænser, hvad der overhovedet har tilladelse til at køre. De beskytter forskellige ting, og du ønsker begge.

Kan det at aktivere dette bryde min side?

Det kan, hvis det aktiveres aggressivt på én gang, fordi det kan blokere legitime scripts du faktisk bruger. Det er grunden til, at standardtilgangen er at starte i en 'report-only' prøvetilstand der ser uden at blokere, fikse alt det flagger, og kun derefter håndhæve det. Gjort på denne måde er det sikkert — og prøvetrinnet er bygget ind i fikset nedenfor.

Vi satte det i 'report-only'-tilstand allerede — er vi dækket?

Nej, og dette er den mest almindelige falske tryghedsfornemmelse. Report-only-tilstand ser og logger, hvad der ville være blokeret, men blokerer ingenting — besøgende får nul reel beskyttelse. Det er kun det sikre første trin. Vores tjek giver report-only en lille brøkdel af creditten af en reel politik og vil ikke notere det som et bestå. Du er kun beskyttet, når du skifter til håndhævelsestilstand.

Påvirker dette vores score, eller er det blot vejledende?

Det påvirker din score. Content Security Policy-tjekket er scoret og op til 25 point værd i kategorien Websikkerhed. En manglende eller svag politik er markeret høj alvorlighed og trækker din karakter ned — og det er præcis den slags hul, en klients sikkerhedsspørgeskema spørger om.

Vores udvikler tilføjede en politik, men scoren er stadig lav — hvorfor?

En politik kan eksistere og stadig være svag. De mest almindelige skyldige er smuthuller som 'unsafe-inline' og 'unsafe-eval' for scripts, eller wildcard-kilder (et bart *), som genåbner præcis det hul, politikken er ment at lukke. Vores tjek læser politikken direktiv for direktiv og scorer ned disse svagheder — en politik der tillader alt, scorer lidt bedre end ikke at have nogen. Fikset er at stramme script-reglerne ved hjælp af nonces eller hashes i stedet for disse smuthuller.