Két biztonsági réteg, amelynek meg kell egyeznie

A Content Security Policy (CSP) megmondja a böngészőnek, mely forrásokból tölthet be az oldal scripteket, stílusokat, képeket, kereteket és hálózati kéréseket. A beleegyezéskezelő platform az ellenkezőjét teszi: a felhasználó döntése alapján határozza meg, ezek közül mely scriptek futhatnak. Ha a kettőt külön konfigurálják, ütköznek. A CMP nem töltődik be, mert a CSP blokkolja, vagy a CSP-t annyira fellazítják a CMP és a hirdetési tagek miatt, hogy már semmit sem véd.

Ez az útmutató elmagyarázza, milyen CSP-direktívákra van általában szüksége egy CMP-nek, hogyan hatnak a noncek a scriptbeszúrásra, és hogyan vezethet be változtatásokat a banner elrontása nélkül.

Mire van általában szüksége a CMP-nek a CSP-től

A pontos követelmények szolgáltatónként eltérnek, ezért mindig a CMP saját dokumentációjából induljon ki. Általánosságban ezeket a direktívákat ellenőrizze:

• script-src — az a domain, ahonnan a CMP script betöltődik, plusz minden további scriptfájl, amelyet betölt.
• connect-src — a végpontok, amelyeket a CMP fetch-csel vagy XHR-rel hív, például a konfiguráció, a szállítólista, a geolokáció és a beleegyezés naplózásának végpontjai.
• style-src — a stíluslap domainje, és esetleg az inline stílusok, ha a CMP <style> elemet szúr be vagy style attribútumokat állít be.
• img-src — logók, ikonok és a CMP által használt, követésmentes pixelek.
• font-src — ha a banner saját betűtípusokat tölt be.
• frame-src — ha a CMP iframe-eket használ, például domainek közötti beleegyezés-megosztáshoz.

TCF-es webhelyeken ne feledje, hogy a CMP egy __tcfapiLocator nevű locator keretet is létrehoz az oldalon. Ez a keret távoli forrás nélkül jön létre, ezért általában nem kell hozzá frame-src bejegyzés, de érdemes tesztelés közben megerősíteni.

Az inline stub problémája

A legtöbb CMP kéri, hogy helyezzen egy kis inline scriptet — a stubot — az oldal fejlécébe, hogy más scriptek sorba állíthassák a hívásaikat a fő CMP betöltése előtt. Egy szigorú CSP blokkolja az inline scripteket, hacsak kifejezetten nem engedélyezi őket. Három lehetősége van:

1. Nonce. Generáljon válaszonként véletlen értéket, adja hozzá a CSP-fejléchez 'nonce-...' formában és a stub <script> tagjéhez. Ez a legrugalmasabb lehetőség dinamikus oldalaknál.
2. Hash. Adja hozzá a stub pontos tartalmának SHA-256 hashét a script-src-hez. Statikus webhelyeknél jól működik, de a stub bármilyen módosítása, még egy szóköz is, elrontja.
3. A stub saját hosztolása külső fájlként a saját domainjén, amelyet a 'self' lefed. Ügyelni kell rá, hogy elég korán betöltődjön.

Kerülje a 'unsafe-inline'-t mint rövidítést. Minden inline scriptet engedélyez, ami a CSP által nyújtott védelem nagy részét megszünteti.

Noncek és a CMP által beszúrt scriptek

Az a CMP, amely a beleegyezésig blokkolja a scripteket, gyakran úgy működik, hogy visszatartja, majd később beszúrja őket. Noncealapú CSP mellett ezeket a beszúrt scripteket is engedélyezni kell. Két gyakori megközelítés van:

• Nonce-továbbítás. A CMP a saját script tagjéből olvassa ki a noncet, és hozzáadja minden beszúrt scripthez. Ellenőrizze, hogy a CMP-je támogatja-e.
• 'strict-dynamic'. Ez a kulcsszó megmondja a támogató böngészőknek, hogy bízzanak egy már megbízott script által betöltött scriptekben. Megkönnyíti az életet a scripteket beszúró tag managerekkel és CMP-kkel, de azt is jelenti, hogy bármely script, amelyben megbízik, más scripteket tölthet be, ezért óvatosan bízzon.

Ugyanezt a kérdést vetik fel a tag managerek. Ha hirdetési és analitikai tageket tag manageren keresztül tölt be, kövesse annak noncere vonatkozó dokumentációját, és gondoskodjon róla, hogy a CMP és a tag manager következetes megközelítést használjon.

A hirdetési tagek nehezítik a CSP-t

A programmatic hirdetés sok domainről tölt be scripteket és kereteket, és a lista a keresleti partnerekkel együtt változik. A kiadók általában két megoldás közül választanak:

• Szigorú CSP a programmatic hirdetések nélküli oldalakon, és tágabb szabályzat ott, ahol hirdetések futnak.
• Olyan szabályzat, amely a kezelhető direktívákra összpontosít, mint a frame-ancestors, az object-src 'none' és a base-uri, miközben a scriptforrások tágabbak maradnak.

Akárhogy is, a CMP-nek az explicit engedélyezőlistán kell lennie, nem csak egy helyettesítő karakter által lefedve, hogy egy CSP-módosítás soha ne kapcsolja ki csendben a bannert.

Vezesse be Report-Only módban

Először a Content-Security-Policy-Report-Only fejlécet használja. A böngésző blokkolás nélkül jelenti a szabálysértéseket, így láthatja, mit rontana el egy új szabályzat.

1. Telepítse a szabályzatot report-only módban egy jelentési végponttal.
2. Töltsön be oldalakat tiszta böngészőprofilokban, és járja végig a teljes beleegyezési folyamatot: első látogatás, mindent elfogad, mindent elutasít, egyéni választás, visszavonás.
3. Nézze át a szabálysértési jelentéseket és a böngészőkonzolt a blokkolt CMP-erőforrások után kutatva.
4. Módosítsa a szabályzatot, majd váltson kikényszerítésre.
5. A kikényszerítés után hagyja bekapcsolva a jelentést a regressziók elkapásához.

A CSP-ütközés tünetei

• A banner soha nem jelenik meg, és a konzol CSP-szabálysértést mutat a CMP scriptre.
• A banner megjelenik, de stílus nélkül, mert a style-src blokkolja a CSS-ét.
• A választások nem mentődnek, mert a connect-src blokkolja a beleegyezést naplózó hívást.
• A hirdetések vagy az analitika a beleegyezés után sem töltődnek be, mert a beszúrt scriptekből hiányzik a nonce.
• A __tcfapi nincs definiálva, mert az inline stubot blokkolták.

Legfontosabb tanulságok

• A CMP-jéhez ellenőrizze a script-src, connect-src, style-src, img-src és frame-src direktívákat.
• Az inline stubot nonce-szal vagy hasheléssel engedélyezze, ne 'unsafe-inline'-nal.
• Gondoskodjon róla, hogy a beleegyezés után beszúrt scriptek noncet kapjanak, vagy a 'strict-dynamic' fedje le őket.
• A kikényszerítés előtt tesztelje az összes beleegyezési utat report-only módban.
• Tartsa a CMP-t explicit engedélyezőlistán, hogy a CSP-változtatások ne kapcsolhassák ki.