To sikkerhetslag som må være enige

En Content Security Policy (CSP) forteller nettleseren hvilke kilder en side kan laste skript, stiler, bilder, frames og nettverksforespørsler fra. En consent management platform gjør det motsatte: den avgjør hvilke av disse skriptene som får kjøre, basert på brukerens valg. Når de to konfigureres hver for seg, kolliderer de. CMP-en lastes ikke fordi CSP blokkerer den, eller CSP-en lempes så mye for å huse CMP-en og annonsetaggene at den ikke lenger beskytter noe.

Denne veiledningen forklarer hvilke CSP-direktiver en CMP vanligvis trenger, hvordan nonces samspiller med skriptinjeksjon, og hvordan du ruller ut endringer uten å ødelegge banneret ditt.

Hva en CMP vanligvis trenger fra CSP

De nøyaktige kravene avhenger av leverandøren, så ta alltid utgangspunkt i CMP-ens egen dokumentasjon. Sjekk generelt disse direktivene:

• script-src — domenet CMP-skriptet lastes fra, pluss eventuelle ekstra skriptfiler det laster.
• connect-src — endepunkter CMP-en kaller med fetch eller XHR, som konfigurasjon, leverandørliste, geolokalisering og endepunkter for samtykkelogging.
• style-src — stilarkets domene, og muligens inline-stiler hvis CMP-en injiserer et <style>-element eller setter style-attributter.
• img-src — logoer, ikoner og eventuelle sporingsfrie piksler CMP-en bruker.
• font-src — hvis banneret laster egne skrifttyper.
• frame-src — hvis CMP-en bruker iframes, for eksempel for deling av samtykke på tvers av domener.

På TCF-nettsteder må du huske at CMP-en også oppretter en locator-frame ved navn __tcfapiLocator på siden. Den framen opprettes uten ekstern kilde, så den trenger normalt ingen frame-src-oppføring, men det er verdt å bekrefte i testing.

Problemet med inline-stubben

De fleste CMP-er ber deg plassere et lite inline-skript — stubben — i sidens head, slik at andre skript kan sette kall i kø før hoved-CMP-en lastes. En streng CSP blokkerer inline-skript med mindre du uttrykkelig tillater dem. Du har tre alternativer:

1. En nonce. Generer en tilfeldig verdi per respons, legg den til CSP-headeren som 'nonce-...' og til stubbens <script>-tagg. Dette er det mest fleksible alternativet for dynamiske sider.
2. En hash. Legg SHA-256-hashen av stubbens nøyaktige innhold til i script-src. Dette fungerer godt for statiske nettsteder, men enhver endring av stubben, selv i mellomrom, ødelegger det.
3. Å selvhoste stubben som en ekstern fil på ditt eget domene, dekket av 'self'. Dette krever omhu for å sikre at den lastes tidlig nok.

Unngå 'unsafe-inline' som snarvei. Det tillater alle inline-skript, noe som fjerner mye av beskyttelsen CSP gir.

Nonces og skript CMP-en injiserer

En CMP som blokkerer skript frem til samtykke fungerer ofte ved å holde dem tilbake og injisere dem senere. Under en nonce-basert CSP må også disse injiserte skriptene tillates. Det finnes to vanlige tilnærminger:

• Nonce-videreføring. CMP-en leser noncen fra sin egen skripttagg og legger den til hvert skript den injiserer. Sjekk om CMP-en din støtter dette.
• 'strict-dynamic'. Dette nøkkelordet forteller støttende nettlesere at de skal stole på skript som lastes av et allerede betrodd skript. Det forenkler livet med tag managers og CMP-er som injiserer skript, men det betyr også at ethvert skript du stoler på kan laste andre, så stol med omhu.

Tag managers reiser det samme spørsmålet. Hvis du laster annonse- og analysetagger gjennom en tag manager, følg dens dokumentasjon om nonces og sørg for at CMP og tag manager bruker en konsistent tilnærming.

Annonsetagger gjør CSP vanskeligere

Programmatisk annonsering laster skript og frames fra mange domener, og listen endres når demand-partnere endres. Utgivere gjør vanligvis ett av to valg:

• En streng CSP på sider uten programmatiske annonser, og en bredere policy der annonser kjører.
• En policy som fokuserer på direktiver som forblir håndterbare, som frame-ancestors, object-src 'none' og base-uri, mens skriptkildene forblir bredere.

Uansett bør CMP-en stå eksplisitt på tillatelseslisten, ikke bare være dekket av et jokertegn, slik at en CSP-endring aldri i det stille deaktiverer banneret.

Rull ut med report-only-modus

Bruk headeren Content-Security-Policy-Report-Only først. Nettleseren rapporterer brudd uten å blokkere noe, slik at du kan se hva en ny policy ville ødelagt.

1. Rull ut policyen i report-only-modus med et rapporteringsendepunkt.
2. Last sider i rene nettleserprofiler og gå gjennom hele samtykkeflyten: første besøk, godta alle, avvis alle, egendefinert valg, tilbaketrekking.
3. Gå gjennom bruddrapportene og nettleserkonsollen etter blokkerte CMP-ressurser.
4. Juster policyen, og bytt deretter til håndheving.
5. La rapporteringen være på etter håndhevingen for å fange regresjoner.

Symptomer på en CSP-konflikt

• Banneret vises aldri, og konsollen viser et CSP-brudd for CMP-skriptet.
• Banneret vises, men uten stil, fordi style-src blokkerer CSS-en.
• Valg lagres ikke, fordi connect-src blokkerer kallet for samtykkelogging.
• Annonser eller analytics lastes aldri etter samtykke, fordi injiserte skript mangler en nonce.
• __tcfapi er udefinert, fordi inline-stubben ble blokkert.

Viktigste poenger

• Sjekk script-src, connect-src, style-src, img-src og frame-src for CMP-en din.
• Tillat inline-stubben med en nonce eller hash, ikke med 'unsafe-inline'.
• Sørg for at skript injisert etter samtykke får en nonce eller er dekket av 'strict-dynamic'.
• Test hver samtykkesti i report-only-modus før du håndhever.
• Hold CMP-en eksplisitt på tillatelseslisten slik at CSP-endringer ikke kan deaktivere den.