Defaults.Exposed › Åtgärder › Content-Security-Policy (CSP)

Hur du fixar Content-Security-Policy (CSP)

En Content Security Policy är en säkerhetsregel din webbplats överlämnar till varje besökares webbläsare, som berättar exakt vilken kod som tillåts köra. Utan en sådan, om något skadligt någonsin hamnar på en sida — via ett kommentarsfält, ett hackat plugin eller ett tredjepartsskript — kör webbläsaren det fritt, inklusive kod som tyst skimmar dina kunders kortnummer och lösenord medan de skriver, med hänglåset fortfarande synligt.

Slutsats för ditt företag: Om din webbplats någonsin manipuleras kan skadlig kod läsa dina kunders betalningskorts- och inloggningsuppgifter direkt från din kassa medan allt ser helt normalt ut — vilket lämnar dig med chargebacks, bedrägerianspråk, ett rapporteringspliktigt dataintrång och en kontrollflagga som säkerhetsteam hos större kunder använder för att stoppa eller döda en affär.

Vad detta kan kosta dig

• Dold kod smyger sig in på en av dina sidor och kopierar tyst varje kortnummer och lösenord som dina kunder anger vid kassan, och skickar det till en angripare medan din webbplats ser helt normal ut — du får bara reda på det när bedrägerianmälningarna anländer.
• En bedragare planterar ett falskt 'betala här'-formulär på din riktiga webbplats som fångar betalningar till sitt eget konto; kunder tror att de betalade dig, skyller på dig när varorna aldrig kommer och kräver sina pengar tillbaka.
• En större kunds säkerhetsteam skannar din webbplats, ser att det här grundläggande skyddet är avslaget, och flaggar det — stoppar eller förlorar dig kontraktet tills du kan bevisa att det är åtgärdat.
• Ett intrång spårat till en saknad standardskyddsåtgärd blir ett rapporteringspliktigt ärende: tillsynsmyndighetsfrågor, kundmeddelanden och en ryktespåverkan som kostar mycket mer än den gratis åtgärden.

Varför det spelar roll. Hänglåset bevisar att anslutningen till din webbplats är privat, men det gör ingenting för att kontrollera vilken kod som körs när en besökare väl är på sidan. En Content Security Policy är skyddsåtgärden som gör det — den berättar för webbläsare att ignorera alla skript som inte kom från en källa du litar på, så att ett enda manipulerat fält, en annons eller ett plugin inte kan förvandlas till ett verktyg för att stjäla dina kunders pengar och data. Det är en betygsatt kontroll på ditt betyg, värd riktiga poäng, och en av de första sakerna en professionell säkerhetsgranskning letar efter.

Vad det här är, i klartext

När någon besöker din webbplats laddar deras webbläsare ned din sida och kör vilken kod som helst som finns på den — skripten som gör att menyer fälls ned, knappar fungerar, betalningsformulär skickas och så vidare. Som standard litar webbläsaren på allt det. Den har inget sätt att veta vilken kod som genuint är din och vilken som smugits in av någon annan.

En Content Security Policy (ofta förkortat CSP) är en kort lista av regler din webbplats kopplar till varje sida, som berättar för webbläsaren: “kör bara kod från dessa källor jag har godkänt, och vägra allt annat.” Det är skillnaden mellan en nattklubb som släpper in vem som helst och en med en gästlista vid dörren.

Orsaken till att det här är så viktigt är att webbplatser manipuleras ständigt — inte alltid genom att hacka din server, utan genom bakdörrarna de flesta webbplatser lämnar öppna: ett kommentarsfält, en sökruta, ett föråldrat plugin, ett tredjepartsskript för annonser eller analys, eller en chattwidget. Om en angripare får ens en rad av sin egen kod på en av dina sidor kör webbläsaren den som om den vore din. Därifrån kan den läsa allt dina kunder skriver — kortnummer, lösenord, adresser — och tyst skicka det någon annanstans. En Content Security Policy stänger den dörren genom att vägra köra något från en källa du inte godkänt.

Vad det här kan kosta dig

Det här är inte abstrakt. Attacken en Content Security Policy förhindrar — kod injicerad på en sida som stjäl data från dina egna kunder — ligger bakom några av de största kortskimningsintrången på rekord. Så här tenderar det att spela ut för ett normalt företag:

• Det osynliga kassaskimmet. En angripare smuglar in ett par kodrader på din kassasida via ett sårbart plugin eller ett komprometterat tredjepartsskript. Varje kortnummer, namn och CVV dina kunder skriver kopieras och skickas till angriparen i realtid. Din webbplats ser ut och fungerar perfekt; hänglåset är där. Du upptäcker det veckor senare när din betalningsleverantör ringer om ett kluster av bedrägerianmälningar som alla spårar tillbaka till din butik. Nu möter du chargebacks, en tvingad säkerhetsrevision, möjlig förlust av kortbehandlingsrättigheter och ett intrång du kanske är lagligen skyldig att rapportera.

• Det falska betalningsformuläret. En bedragare injicerar en övertygande “betala här”-ruta på din riktiga webbplats. Kunder anger sina uppgifter och litar på ditt varumärke; pengarna och datan går till angriparen. Kunderna skyllar på dig — och de har rätt att göra det, för det hände på din webbplats.

• Det förlorade kontraktet. En större potentiell kunds säkerhetsteam kör en automatiserad skanning av din webbplats som en del av leverantörsdue diligence. En saknad Content Security Policy dyker upp omedelbart som ett högt allvarlighetsgrad-gap. För en inköps- eller säkerhetsgranskare läses det här enda saknade skyddet som “den här leverantören gör inte grunderna” — och affären stannar medan de begär sanering, eller går tyst till en konkurrent som klarade sig.

• Det rapporteringspliktige intrånget. När ett dataintrång spåras tillbaka till en saknad, standard, gratis skyddsåtgärd slutar det att se ut som otur och börjar se ut som vårdslöshet. Det ändrar tillsynsmyndighetens frågor, skyldigheten att meddela kunder och kostnaden — både boten och ryktespåverkan, som kvarstår länge efter att incidenten är stängd.

• Det komprometterade reklamet eller widgeten. Många webbplatser laddar kod från utomstående parter — annonsnätverk, teckensnitt, stöd-chatt, analys. Om något av de komprometteras rider den skadliga koden rakt in på dina sidor. En Content Security Policy begränsar skaderadien genom att bara tillåta de specifika utomstående källorna du litar på, så att en leverantörs intrång inte automatiskt blir ditt.

Vad det faktiskt är (detaljen)

En Content Security Policy levereras som ett enda HTTP-svarshuvud — en rad din webbserver skickar med varje sida. Dess värde är en uppsättning direktiv, var och en namnger en typ av innehåll och de tillåtna källorna för det. Till exempel:

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

I klartext säger det: ladda som standard bara saker från min egen webbplats; kör bara skript från min egen webbplats; tillåt inga gamla plugins; och låt inte andra webbplatser bädda in min i en ram.

Vad “bra” ser ut som. Vår kontroll tittar inte bara på huvudets närvaro — den läser policyn direktiv för direktiv och betygsätter hur stark den faktiskt är, på det sätt en säkerhetsgranskare skulle. En stark policy:

• Sätter en restriktiv baslinje (default-src 'self') och breddar den bara för de specifika betrodda tredjeparterna du genuint använder.
• Undviker kryphålen. Den använder inte 'unsafe-inline' eller 'unsafe-eval' för skript, och använder inte jokertecken (*) eller bara schemakällor (som https:) för skript — dessa återöppnar i praktiken den dörr policyn är avsedd att stänga. Där inline-skript genuint behövs använder den ett nonce eller hash så att bara din specifika godkända kod körs.
• Låser ned inramning med frame-ancestors 'self' och inaktiverar legacy plugins med object-src 'none'.
• Verkställer, inte bara report-only. Ett Content-Security-Policy-Report-Only-huvud observerar bara; det ger noll körtidsskydd. Vår kontroll ger det en liten bråkdel av krediterna och registrerar det aldrig som godkänt. Du är bara skyddad när policyn verkställs.

Så här åtgärdar du det (gratis, ~1–2 timmar)

Skicka det här till din IT-person eller den som driver din webbplats — åtgärden i sig är helt gratis. Vi tar bara betalt för att övervaka att den förblir på plats och förblir korrekt över tid; att slå på den kostar ingenting. Orsaken till att det tar en timme eller två snarare än minuter är det noggranna provsteget som förhindrar att det av misstag blockerar delar av din egen webbplats.

1. Börja i report-only-läge — verkställ inte ännu. Lägg till ett Content-Security-Policy-Report-Only-svarshuvud. Det observerar och loggar vad som skulle blockeras utan att faktiskt blockera något, så den live-webbplatsen fortsätter fungera medan du lär dig vad varje sida genuint beror på. (Viktigt: report-only ensamt ger besökare inget skydd — det är bara det säkra första steget.)

2. Bygg policyn från vad din webbplats faktiskt använder. Granska rapporterna för att hitta varje legitim källa av skript, stilar, teckensnitt och bilder — din egen domän, din analys, din betalningsleverantör, din teckensnittsvärd, din chattwidget — och lista dem som tillåtna källor. En solid startpunkt är default-src 'self' plus explicita poster för de betrodda tredjeparterna du verkligen använder.

3. Undvik kryphålen som besegrar hela poängen. Styr undan från 'unsafe-inline' och 'unsafe-eval' för skript, och undvik jokerteckenkällor som * och bara scheman som https: för skript — dessa återöppnar exakt det gap policyn är avsedd att stänga. Där inline-skript är oundvikliga, använd ett nonce eller hash så att bara din specifika godkända kod körs.

4. Lås ned inramning och plugins. Lägg till frame-ancestors 'self' (det här stoppar också att andra webbplatser bäddar in din för att lura dina kunder, och det tillfredsställer den relaterade clickjacking-kontrollen) och object-src 'none' för att blockera legacy plugin-baserade attacker.

5. Byt från report-only till verkställande. När rapporterna är rena och webbplatsen fungerar, ändra huvud-namnet från Content-Security-Policy-Report-Only till Content-Security-Policy. Det här är steget som faktiskt levererar skydd — en report-only policy ensam gör det inte, och klarar inte kontrollen.

   Var du sätter huvudet beror på din plattform:

   • Cloudflare: Regler → Omvandlingsregler → Ändra svarshuvud → sätt 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): lägg till ett anpassat HTTP-svarshuvud med namnet Content-Security-Policy och policyn som dess värde.

6. Kontrollera din domän igen för att bekräfta att policyn nu visas som påslagen och verkställande, utan försvagande kryphål.

Vanliga misstag

• Stanna vid report-only. Det enskilda vanligaste felet: en policy läggs till i report-only-läge, alla går vidare, och webbplatsen är aldrig faktiskt skyddad. Report-only blockerar ingenting. Du måste byta till verkställande.
• Ta till 'unsafe-inline' för att göra det “bara fungera”. När policyn blockerar ett legitimt inline-skript är den snabba åtgärden att tillåta alla inline-skript — men det återöppnar exakt det hål policyn var avsedd att stänga. Använd ett nonce eller hash istället.
• Använda ett jokertecken. Ett blott * (eller https:) i script-src tillåter skript varifrån som helst, vilket innebär att policyn ger nästan inget verkligt skydd och fortfarande ger lågt betyg.
• Glömma tredjepartskällor. Att verkställa en strikt policy utan att först lista de legitima utomstående tjänster du använder (analys, teckensnitt, betalningswidgets) kan bryta delar av din egen webbplats — vilket är exakt varför report-only-provsteget finns.
• Sätta det bara på hemsidan. Policyn måste täcka varje sida, speciellt kassa, inloggning och kontosidor — de är de som är värda att attackera.
• Behandla det som en ersättning för hänglåset. En Content Security Policy och HTTPS/HSTS skyddar olika saker. Du vill ha alla av dem; en täcker inte för en annan.

Vanliga frågor