To sikkerhedslag, der skal være enige

En Content Security Policy (CSP) fortæller browseren, hvilke kilder en side må indlæse scripts, typografier, billeder, frames og netværksforespørgsler fra. En consent management platform gør det modsatte: den afgør, hvilke af disse scripts der må køre, ud fra brugerens valg. Når de to konfigureres hver for sig, støder de sammen. CMP'en indlæses ikke, fordi CSP blokerer den, eller CSP'en lempes så meget for at rumme CMP'en og annoncetags, at den ikke længere beskytter noget.

Denne vejledning forklarer, hvilke CSP-direktiver en CMP typisk har brug for, hvordan nonces spiller sammen med scriptinjektion, og hvordan du udruller ændringer uden at ødelægge dit banner.

Hvad en CMP normalt har brug for fra CSP

De præcise krav afhænger af leverandøren, så tag altid udgangspunkt i din CMP's egen dokumentation. Tjek generelt disse direktiver:

• script-src — domænet, CMP-scriptet indlæses fra, plus eventuelle yderligere scriptfiler, det indlæser.
• connect-src — endpoints, CMP'en kalder med fetch eller XHR, såsom konfiguration, leverandørliste, geolokalisering og endpoints til samtykkelogning.
• style-src — stylesheetets domæne og muligvis inline-typografier, hvis CMP'en injicerer et <style>-element eller sætter style-attributter.
• img-src — logoer, ikoner og eventuelle sporingsfri pixels, CMP'en bruger.
• font-src — hvis banneret indlæser egne skrifttyper.
• frame-src — hvis CMP'en bruger iframes, for eksempel til deling af samtykke på tværs af domæner.

På TCF-websteder skal du huske, at CMP'en også opretter en locator-frame ved navn __tcfapiLocator på siden. Den frame oprettes uden en ekstern kilde, så den behøver normalt ikke en frame-src-post, men det er værd at bekræfte i test.

Problemet med inline-stubben

De fleste CMP'er beder dig placere et lille inline-script — stubben — i sidens head, så andre scripts kan sætte kald i kø, før hoved-CMP'en indlæses. En streng CSP blokerer inline-scripts, medmindre du udtrykkeligt tillader dem. Du har tre muligheder:

1. En nonce. Generér en tilfældig værdi pr. svar, tilføj den til CSP-headeren som 'nonce-...' og til stubbens <script>-tag. Det er den mest fleksible mulighed til dynamiske sider.
2. En hash. Tilføj SHA-256-hashen af stubbens præcise indhold til script-src. Det fungerer godt for statiske websteder, men enhver ændring af stubben, selv af blanktegn, ødelægger det.
3. At selvhoste stubben som en ekstern fil på dit eget domæne, dækket af 'self'. Det kræver omhu for at sikre, at den indlæses tidligt nok.

Undgå 'unsafe-inline' som genvej. Det tillader ethvert inline-script, hvilket fjerner meget af den beskyttelse, CSP giver.

Nonces og scripts, CMP'en injicerer

En CMP, der blokerer scripts indtil samtykke, virker ofte ved at holde dem tilbage og injicere dem senere. Under en nonce-baseret CSP skal disse injicerede scripts også tillades. Der er to almindelige tilgange:

• Nonce-videregivelse. CMP'en læser noncen fra sit eget script-tag og tilføjer den til hvert script, den injicerer. Tjek, om din CMP understøtter det.
• 'strict-dynamic'. Dette nøgleord fortæller understøttende browsere, at de skal stole på scripts, der indlæses af et allerede betroet script. Det gør livet lettere med tag managers og CMP'er, der injicerer scripts, men det betyder også, at ethvert script, du stoler på, kan indlæse andre, så stol med omtanke.

Tag managers rejser det samme spørgsmål. Hvis du indlæser annonce- og analysetags gennem en tag manager, så følg dens dokumentation om nonces, og sørg for, at CMP og tag manager bruger en konsistent tilgang.

Annoncetags gør CSP sværere

Programmatisk annoncering indlæser scripts og frames fra mange domæner, og listen ændrer sig, efterhånden som demand-partnere skifter. Udgivere træffer som regel ét af to valg:

• En streng CSP på sider uden programmatiske annoncer og en bredere politik, hvor annoncer kører.
• En politik, der fokuserer på direktiver, der forbliver overskuelige, såsom frame-ancestors, object-src 'none' og base-uri, mens scriptkilderne forbliver bredere.

Uanset hvad bør CMP'en stå eksplicit på tilladelseslisten og ikke kun være dækket af et jokertegn, så en CSP-ændring aldrig i det stille deaktiverer banneret.

Udrul med report-only-tilstand

Brug først headeren Content-Security-Policy-Report-Only. Browseren rapporterer overtrædelser uden at blokere noget, så du kan se, hvad en ny politik ville ødelægge.

1. Udrul politikken i report-only-tilstand med et rapporteringsendpoint.
2. Indlæs sider i rene browserprofiler, og gennemgå hele samtykkeforløbet: første besøg, accepter alle, afvis alle, brugerdefineret valg, tilbagetrækning.
3. Gennemgå overtrædelsesrapporterne og browserkonsollen for blokerede CMP-ressourcer.
4. Justér politikken, og skift derefter til håndhævelse.
5. Lad rapporteringen være slået til efter håndhævelsen for at fange regressioner.

Symptomer på en CSP-konflikt

• Banneret vises aldrig, og konsollen viser en CSP-overtrædelse for CMP-scriptet.
• Banneret vises, men uden typografi, fordi style-src blokerer dets CSS.
• Valg gemmes ikke, fordi connect-src blokerer kaldet til samtykkelogning.
• Annoncer eller analytics indlæses aldrig efter samtykke, fordi injicerede scripts mangler en nonce.
• __tcfapi er udefineret, fordi inline-stubben blev blokeret.

Vigtigste pointer

• Tjek script-src, connect-src, style-src, img-src og frame-src for din CMP.
• Tillad inline-stubben med en nonce eller hash, ikke med 'unsafe-inline'.
• Sørg for, at scripts injiceret efter samtykke får en nonce eller er dækket af 'strict-dynamic'.
• Test hver samtykkesti i report-only-tilstand, før du håndhæver.
• Hold CMP'en eksplicit på tilladelseslisten, så CSP-ændringer ikke kan deaktivere den.