Två säkerhetslager som måste vara överens

En Content Security Policy (CSP) talar om för webbläsaren från vilka källor en sida får ladda skript, stilar, bilder, ramar och nätverksanrop. En plattform för samtyckeshantering gör det motsatta jobbet: den avgör vilka av dessa skript som får köras utifrån användarens val. När de två konfigureras separat kolliderar de. CMP:n laddas inte eftersom CSP blockerar den, eller så lättas CSP upp så mycket för att rymma CMP:n och annonstaggarna att den inte längre skyddar något.

Den här guiden förklarar vilka CSP-direktiv en CMP vanligtvis behöver, hur nonces samspelar med skriptinjektion och hur du rullar ut ändringar utan att bryta bannern.

Vad en CMP vanligtvis behöver från CSP

Exakta krav beror på leverantören, så utgå alltid från din CMP:s egen dokumentation. I allmänhet bör du kontrollera dessa direktiv:

• script-src — domänen som CMP-skriptet laddas från, plus eventuella ytterligare skriptfiler det laddar.
• connect-src — slutpunkter som CMP:n anropar med fetch eller XHR, såsom konfiguration, leverantörslista, geolokalisering och loggning av samtycke.
• style-src — stilmallens domän, och möjligen inbäddade stilar om CMP:n injicerar ett <style>-element eller sätter stilattribut.
• img-src — logotyper, ikoner och eventuella spårningsfria pixlar som CMP:n använder.
• font-src — om bannern laddar egna typsnitt.
• frame-src — om CMP:n använder iframes, till exempel för att dela samtycke över domäner.

På TCF-webbplatser, kom ihåg att CMP:n också skapar en lokaliseringsram med namnet __tcfapiLocator på sidan. Den ramen skapas utan någon fjärrkälla, så den behöver normalt ingen frame-src-post, men det är värt att bekräfta vid testning.

Problemet med den inbäddade stubben

De flesta CMP:er ber dig placera ett litet inbäddat skript — stubben — i sidans head, så att andra skript kan köa anrop innan huvud-CMP:n laddats. En strikt CSP blockerar inbäddade skript om du inte uttryckligen tillåter dem. Du har tre alternativ:

1. En nonce. Generera ett slumpmässigt värde per svar, lägg till det i CSP-huvudet som 'nonce-...' och i stubbens <script>-tagg. Det är det mest flexibla alternativet för dynamiska sidor.
2. En hash. Lägg till SHA-256-hashen av stubbens exakta innehåll i script-src. Det fungerar bra för statiska webbplatser, men varje ändring av stubben, även ett blanksteg, bryter det.
3. Egen hosting av stubben som en extern fil på din egen domän, täckt av 'self'. Det kräver omsorg för att den ska laddas tillräckligt tidigt.

Undvik 'unsafe-inline' som genväg. Det tillåter varje inbäddat skript, vilket tar bort mycket av det skydd CSP ger.

Nonces och skript som CMP:n injicerar

En CMP som blockerar skript till dess samtycke finns fungerar ofta genom att hålla tillbaka dem och injicera dem senare. Under en nonce-baserad CSP måste även dessa injicerade skript tillåtas. Det finns två vanliga tillvägagångssätt:

• Nonce-propagering. CMP:n läser nonce från sin egen skripttagg och lägger till den på varje skript den injicerar. Kontrollera om din CMP stöder detta.
• 'strict-dynamic'. Det här nyckelordet säger åt webbläsare som stöder det att lita på skript som laddats av ett redan betrott skript. Det förenklar livet med tagghanterare och CMP:er som injicerar skript, men det betyder också att varje skript du litar på kan ladda andra, så lita med eftertanke.

Tagghanterare väcker samma fråga. Om du laddar annons- och analystaggar via en tagghanterare, följ dess dokumentation om nonces och se till att CMP:n och tagghanteraren använder ett konsekvent tillvägagångssätt.

Annonstaggar gör CSP svårare

Programmatisk annonsering laddar skript och ramar från många domäner, och listan ändras när efterfrågepartner ändras. Utgivare gör vanligtvis ett av två val:

• En strikt CSP på sidor utan programmatiska annonser och en bredare policy där annonser körs.
• En policy som fokuserar på direktiv som förblir hanterbara, såsom frame-ancestors, object-src 'none' och base-uri, medan skriptkällorna förblir bredare.

Hur som helst bör CMP:n finnas i den uttryckliga tillåtelselistan, inte bara täckas av ett jokertecken, så att en CSP-ändring aldrig tyst stänger av bannern.

Rulla ut med report-only-läge

Använd huvudet Content-Security-Policy-Report-Only först. Webbläsaren rapporterar överträdelser utan att blockera något, så att du ser vad en ny policy skulle bryta.

1. Driftsätt policyn i report-only-läge med en rapporteringsslutpunkt.
2. Ladda sidor i rena webbläsarprofiler och gå igenom hela samtyckesflödet: första besöket, acceptera alla, avvisa alla, anpassat val, återkallande.
3. Granska överträdelserapporterna och webbläsarkonsolen efter blockerade CMP-resurser.
4. Justera policyn och byt sedan till tillämpning.
5. Låt rapporteringen vara aktiverad efter tillämpning för att fånga regressioner.

Symptom på en CSP-konflikt

• Bannern visas aldrig och konsolen visar en CSP-överträdelse för CMP-skriptet.
• Bannern visas men utan stil, eftersom style-src blockerar dess CSS.
• Val sparas inte, eftersom connect-src blockerar anropet som loggar samtycket.
• Annonser eller analys laddas aldrig efter samtycke, eftersom injicerade skript saknar nonce.
• __tcfapi är odefinierat, eftersom den inbäddade stubben blockerades.

Viktiga slutsatser

• Kontrollera script-src, connect-src, style-src, img-src och frame-src för din CMP.
• Tillåt den inbäddade stubben med en nonce eller hash, inte 'unsafe-inline'.
• Se till att skript som injiceras efter samtycke får en nonce eller täcks av 'strict-dynamic'.
• Testa varje samtyckesväg i report-only-läge innan du tillämpar.
• Håll CMP:n uttryckligen tillåtelselistad så att CSP-ändringar inte kan stänga av den.