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

Slik fikser du Content-Security-Policy (CSP)

En Content Security Policy er en sikkerhetsregel nettstedet ditt gir alle besøkeres nettlesere, og forteller dem nøyaktig hvilken kode som har lov til å kjøre. Uten en, hvis noe skadelig noen gang lander på en side — gjennom en kommentarboks, et hacket plugin, eller et tredjeparts skript — vil nettleseren kjøre det fritt, inkludert kode som stille skimmer kundenes kortnumre og passord mens de skriver, med hengelåsen fortsatt synlig.

Bunnlinjen for virksomheten din: Hvis siden noen gang manipuleres, kan skadelig kode lese kundenes betalingskort- og påloggingsdetaljer rett av kassen din mens alt ser helt normalt ut — og etterlater deg med tilbakebetalinger, svindelpåstander, et rapporteringspliktig databrudd, og en sjekkfeil som større kunders sikkerhetsteam bruker til å stalle eller drepe en avtale.

Hva dette kan koste deg

Skjult kode sniker seg inn på en av sidene og kopierer stille hvert kortnummer og passord kundene skriver inn ved kassen, og sender det til en angriper mens siden ser helt normal ut — du finner det bare ut når svindelklagene ankommer.
En svindler planter et falskt 'betal her'-skjema på det ekte nettstedet ditt som fanger betalinger på sin konto; kunder tror de betalte deg, skyldte på deg når varene aldri kom, og krever pengene tilbake.
Et større selskaps sikkerhetsteam skanner siden, ser at denne grunnleggende beskyttelsen er slått av, og flagget det — staller eller taper deg kontrakten til du kan bevise at det er fikset.
Et brudd sporet til et manglende standardtiltak blir en rapporteringspliktig hendelse: spørsmål fra tilsynsmyndigheter, varsler til kunder og et omdømmeskudd som koster langt mer enn den gratis fiksen.

Hvorfor det er viktig. Hengelåsen beviser at tilkoblingen til siden er privat, men den gjør ingenting for å kontrollere hvilken kode som kjører når besøkende er på siden. En Content Security Policy er sikkerhetstiltaket som gjør det — den forteller nettlesere å ignorere skript som ikke kom fra en kilde du stoler på, slik at ett manipulert felt, annonse eller plugin ikke kan bli et verktøy for å stjele kundenes penger og data. Det er en scoret sjekk på karakterkortet ditt, verdt reelle poeng, og ett av de første tingene en profesjonell sikkerhetsgjennomgang ser etter.

Hva dette er, i enkle ord

Når noen besøker nettstedet ditt, laster nettleseren ned siden og kjører hva enn kode som er på den — skriptene som får menyer til å falle ned, knapper til å fungere, betalingsskjemaer til å sende, og så videre. Som standard stoler nettleseren på alt. Den har ingen måte å vite hvilken kode som genuint er din og hvilken som ble smuglet inn av noen andre.

En Content Security Policy (ofte forkortet til CSP) er en kort liste med regler nettstedet ditt fester til alle sider, og forteller nettleseren: «kjør bare kode fra disse kildene jeg har godkjent, og avvis alt annet.» Det er forskjellen mellom et nattklubben som lar alle inn og en med en gjesteliste ved døren.

Grunnen til at dette betyr så mye er at nettsteder manipuleres konstant — ikke alltid ved å hacke serveren din, men gjennom bakdørene de fleste nettsteder lar stå åpne: et kommentarfelt, en søkeboks, et utdatert plugin, et tredjeparts skript for annonser eller analyse, eller en chat-widget. Hvis en angriper får selv én linje av sin egen kode inn på en av sidene dine, kjører nettleseren det som om det var ditt. Derfra kan det lese alt kundene skriver — kortnumre, passord, adresser — og stille sende det andre steder. En Content Security Policy lukker den døren ved å nekte å kjøre noe fra en kilde du ikke godkjente.

Hva dette kan koste deg

Dette er ikke abstrakt. Angrepet en Content Security Policy forhindrer — kode injisert på en side som stjeler data fra dine egne kunder — er bak noen av de største kortskimmingsbruddene på rekord. Her er hvordan det pleier å utspille seg for en normal virksomhet:

Den usynlige kasseskimmeren. En angriper slipper noen få linjer kode inn på kassesiden din gjennom et sårbart plugin eller et kompromittert tredjeparts skript. Hvert kortnummer, navn og CVV kundene skriver, kopieres og sendes til angriperen i sanntid. Siden ser ut og fungerer perfekt; hengelåsen er der. Du oppdager det uker senere når betalingsleverandøren ringer om en klynge av svindelmeldinger alle sporende tilbake til butikken din. Nå møter du tilbakebetalinger, en tvungen sikkerhetsrevisjon, mulig tap av kortbehandlingsrettigheter og et brudd du kan være juridisk forpliktet til å rapportere.
Det falske betalingsskjemaet. En svindler injiserer en overbevisende «betal her»-boks på det ekte nettstedet ditt. Kunder skriver inn detaljer og stoler på merket ditt; pengene og dataene går til angriperen. Kundene skylder på deg — og de tar ikke feil, fordi det skjedde på siden din.
Den tapte kontrakten. Et større prospekts sikkerhetsteam kjører en automatisk skanning av siden din som del av leverandørgjennomgang. En manglende Content Security Policy vises umiddelbart som et høy-alvorlighetsgap. For en innkjøps- eller sikkerhetsrevisor leses den ene manglende sikkerhetsinnstillingen som «denne leverandøren gjør ikke det grunnleggende» — og avtalen staller mens de ber om utbedring, eller stille går til en konkurrent som bestod.
Det rapporteringspliktige bruddet. Når et databrudd spores tilbake til en manglende, standard, gratis sikkerhetstiltak, slutter det å se ut som uflaks og begynner å se ut som uaktsomhet. Det endrer tilsynsmyndighetens spørsmål, varslingsplikten til kunder og kostnadene — både boten og omdømmeskaden, som varer lenge etter at hendelsen er avsluttet.
Den kompromitterte annonsen eller widgeten. Mange nettsteder laster kode fra utenforstående — annonseNettverk, skrifttyperm støtte-chat, analyse. Hvis noen av disse kompromitteres, rir den skadelige koden rett inn på sidene dine. En Content Security Policy begrenser spredningsradius ved bare å tillate de spesifikke utenforstående kildene du stoler på, slik at en leverandørs brudd ikke automatisk blir ditt.

Hva det faktisk er (detaljen)

En Content Security Policy leveres som én enkelt HTTP-svarhodet — en linje serveren sender med alle sider. Verdien er et sett med direktiver, der hvert navngir en innholdstype og kildene som er tillatt for den. For eksempel:

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

På vanlig norsk sier det: last som standard bare ting fra min egen side; kjør bare skript fra min egen side; ikke tillat gamle typer plugins; og ikke la andre nettsteder bygge inn min side i en ramme.

Hva «bra» ser ut som. Sjekken vår leter ikke bare etter tilstedeværelsen av toppteksten — den leser policyen direktiv for direktiv og scorer hvor sterk den faktisk er, slik en sikkerhetsrevisor ville gjort. En sterk policy:

Setter en restriktiv grunnlinje (default-src 'self') og utvider den bare for de spesifikke betrodde tredjeparter du genuint bruker.
Unngår smutthullene. Den bruker ikke 'unsafe-inline' eller 'unsafe-eval' for skript, og bruker ikke jokertegn (*) eller bare skjemakilder (som https:) for skript — disse gjenåpner effektivt døren policyen er ment å lukke. Der innebygde skript genuint er nødvendige, bruker den et nonce eller hash slik at bare den spesifikke godkjente koden kjøres.
Låser ned innrammering med frame-ancestors 'self' (dette blokkerer også angrepet «legg inn siden for å lure kundene dine») og deaktiverer eldre plugins med object-src 'none'.
Er håndhevende, ikke kun-rapport. En Content-Security-Policy-Report-Only-topptekst ser bare; den gir null kjøretidsbeskyttelse. Sjekken vår gir den en liten brøkdel av kreditten og registrerer den aldri som bestått. Du er bare beskyttet når policyen er håndhevende.

En policy som eksisterer men støtter seg på 'unsafe-inline', 'unsafe-eval' eller jokertegn vil fortsatt score dårlig — fordi den i praksis gir lite ekte beskyttelse. Målet er en stram policy, ikke bare en policy.

Slik fikser du det (gratis, ~1–2 timer)

Send dette til IT-personen din eller den som driver nettstedet — fiksen selv er helt gratis. Vi tar bare betalt for å overvåke at den forblir på plass og forblir riktig over tid; å slå den på koster ingenting. Grunnen til at dette tar en time eller to i stedet for minutter er det nøye prøvesteget som stopper det fra å utilsiktet blokkere deler av din egen side.

Start i kun-rapport-modus — ikke håndhev ennå. Legg til en Content-Security-Policy-Report-Only-svarhodet. Dette ser og logger hva som ville blitt blokkert uten å faktisk blokkere noe, slik at den live siden fortsetter å fungere mens du lærer hva alle sider genuint er avhengige av.
Bygg policyen fra det siden faktisk bruker. Gjennomgå rapportene for å finne alle legitime kilder til skript, stiler, skrifttyper og bilder — ditt eget domene, analysen, betalingsleverandøren, skrifttypeverten, chat-widgeten — og list dem som tillatte kilder.
Unngå smutthullene som beseirer hele poenget. Unngå 'unsafe-inline' og 'unsafe-eval' for skript, og unngå jokertegnkilder som * og bare ordninger som https: for skript. Der innebygde skript er uunngåelige, bruk et nonce eller hash.
Lås ned innrammering og plugins. Legg til frame-ancestors 'self' (dette stopper også andre nettsteder fra å bygge inn ditt for å lure kundene dine) og object-src 'none'.
Bytt fra kun-rapport til håndhevende. Når rapportene er rene og siden fungerer, endre topptekstnavnet fra Content-Security-Policy-Report-Only til Content-Security-Policy. Dette er steget som faktisk leverer beskyttelse — en kun-rapport-policy alene gjør det ikke, og vil ikke bestå sjekken.

Hvor du setter toppteksten avhenger av plattformen:
- Cloudflare: Regler → Transformasjonsregler → Modifiser svarhodet → sett 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';"
- IIS (web.config): legg til et egendefinert HTTP-svarhodet kalt Content-Security-Policy med policyen som verdi.
- Google Workspace / Microsoft 365: disse driver e-posten din, ikke det offentlige nettstedet, så policyen settes der nettstedet faktisk er hostet (Cloudflare eller webhotellet ovenfor), ikke i e-postadminkonsollen.
Sjekk domenet på nytt for å bekrefte at policyen nå vises som slått på og håndhevende, uten svekkende smutthull.

Vanlige feil

Stoppe ved kun-rapport. Den aller vanligste feilen: en policy legges til i kun-rapport-modus, alle går videre, og siden er aldri faktisk beskyttet. Kun-rapport blokkerer ingenting. Du må bytte til håndhevende.
Ty til 'unsafe-inline' for å få det til å «bare fungere». Når policyen blokkerer et legitimt innebygd skript, er den raske fiksen å tillate alle innebygde skript — men det gjenåpner nøyaktig hullet policyen var ment å lukke. Bruk et nonce eller hash i stedet.
Bruke et jokertegn. Et bart * (eller https:) i script-src tillater skript fra hvor som helst, noe som betyr at policyen gir nesten ingen ekte beskyttelse og fortsatt vil score lavt.
Glemme tredjeparts-kilder. Å håndheve en streng policy uten først å liste de legitime utenforstående tjenestene du bruker (analyse, skrifttyper, betalingswidgets) kan bryte deler av siden — noe som er nøyaktig grunnen til at kun-rapport-prøvesteget eksisterer.
Sette den bare på hjemmesiden. Policyen trenger å dekke alle sider, spesielt kassen, innloggings- og kontosider — de er de som er verdt å angripe.
Behandle den som erstatning for hengelåsen. En Content Security Policy og HTTPS/HSTS beskytter forskjellige ting. Du vil ha alle; én dekker ikke for en annen.

FAQ

Jeg er ikke teknisk anlagt — kan jeg ordne dette selv?

Du trenger ikke forstå detaljene. Det er en innstilling lagt til av den som driver nettstedet eller webhotellet, og på tjenester som Cloudflare er det i stor grad veiledet. Send dem «Slik fikser du det»-seksjonen nedenfor. Det er gratis; den ene forsiktigheten er at det bør rulles ut nøye i en kun-se-modus-prøve først slik at det ikke utilsiktet blokkerer deler av din egen side — noe som er nøyaktig det stegene dekker.

Jeg har allerede hengelåsen og et SSL-sertifikat — er ikke siden sikker?

Hengelåsen sikrer leveransen av siden; den politiserer ikke hva som kjøres inne i den. Hvis skadelig kode noen gang havner på en side — via et hacket plugin, en kompromittert annonse, eller et injisert felt — vil ikke hengelåsen stoppe den fra å stjele data. En Content Security Policy er laget som begrenser hva som har lov til å kjøre i utgangspunktet. De beskytter forskjellige ting, og du vil ha begge.

Kan det å slå dette på ødelegge siden min?

Det kan det, hvis det slås på aggressivt på én gang, fordi det kan blokkere legitime skript du faktisk bruker. Det er grunnen til at standardtilnærmingen er å starte i en 'kun rapport'-prøvemodus som ser uten å blokkere, fikse alt den flagget, og bare deretter håndheve den. Gjort på den måten er det trygt — og prøvesteget er innebygd i fiksen nedenfor.

Vi satte den allerede i 'kun rapport'-modus — er vi dekket?

Nei, og dette er den vanligste falske trygghetsfølelsen. Kun rapport-modus ser og logger hva som ville blitt blokkert, men det blokkerer ingenting — besøkende får null ekte beskyttelse. Det er bare det trygge første steget. Sjekken vår gir kun rapport en liten brøkdel av kreditten til en ekte policy og vil ikke registrere det som bestått. Du er bare beskyttet når du bytter til håndhevingsmodus.

Påvirker dette scoren vår, eller er det bare rådgivende?

Det påvirker scoren din. Content Security Policy-sjekken er scoret og verdt opptil 25 poeng i web-sikkerhetskategorien. En manglende eller svak policy er merket som høy alvorlighetsgrad og trekker ned karakteren — og det er nøyaktig det slags gap en klients sikkerhets-spørreskjema spør om.

Utvikleren vår la til en policy, men scoren er fortsatt lav — hvorfor?

En policy kan eksistere og fortsatt være svak. De vanligste problemene er smutthull som 'unsafe-inline' og 'unsafe-eval' for skript, eller jokertegnkilder (et bart *), som gjenåpner nøyaktig det gapet policyen er ment å lukke. Sjekken vår leser policyen direktiv for direktiv og scorer ned disse svakhetene — en policy som tillater hva som helst scorer lite bedre enn å ikke ha noen. Fiksen er å stramme inn skriptreglene ved hjelp av nonces eller hashes i stedet for disse smutthullene.