Kaksi turvakerrosta, joiden on sovittava yhteen

Content Security Policy (CSP) kertoo selaimelle, mistä lähteistä sivu saa ladata skriptejä, tyylejä, kuvia, kehyksiä ja verkkopyyntöjä. Suostumuksenhallinta-alusta tekee päinvastaista työtä: se päättää käyttäjän valinnan perusteella, mitkä näistä skripteistä saavat toimia. Kun nämä kaksi määritetään erikseen, ne törmäävät. CMP ei lataudu, koska CSP estää sen, tai CSP:tä höllennetään CMP:n ja mainostagien mahduttamiseksi niin paljon, ettei se enää suojaa mitään.

Tämä opas selittää, mitä CSP-direktiivejä CMP yleensä tarvitsee, miten noncet vaikuttavat skriptien injektointiin ja miten muutokset otetaan käyttöön rikkomatta banneria.

Mitä CMP yleensä tarvitsee CSP:ltä

Tarkat vaatimukset riippuvat toimittajasta, joten aloita aina CMP:si omasta dokumentaatiosta. Yleisesti tarkista nämä direktiivit:

• script-src — verkkotunnus, josta CMP-skripti latautuu, sekä mahdolliset muut skriptitiedostot, joita se lataa.
• connect-src — päätepisteet, joita CMP kutsuu fetchillä tai XHR:llä, kuten määritys-, toimittajaluettelo-, sijainti- ja suostumuksen kirjauspäätepisteet.
• style-src — tyylitiedoston verkkotunnus ja mahdollisesti inline-tyylit, jos CMP injektoi <style>-elementin tai asettaa tyylimääritteitä.
• img-src — logot, kuvakkeet ja kaikki seurantavapaat pikselit, joita CMP käyttää.
• font-src — jos banneri lataa omat fonttinsa.
• frame-src — jos CMP käyttää iframeja, esimerkiksi suostumuksen jakamiseen verkkotunnusten välillä.

TCF-sivustoilla muista, että CMP luo sivulle myös paikannuskehyksen nimeltä __tcfapiLocator. Tämä kehys luodaan ilman etälähdettä, joten se ei yleensä tarvitse frame-src-merkintää, mutta se kannattaa varmistaa testauksessa.

Inline-stubin ongelma

Useimmat CMP:t pyytävät sijoittamaan sivun head-osaan pienen inline-skriptin — stubin —, jotta muut skriptit voivat jonottaa kutsuja ennen pää-CMP:n latautumista. Tiukka CSP estää inline-skriptit, ellet salli niitä nimenomaisesti. Sinulla on kolme vaihtoehtoa:

1. Nonce. Luo satunnainen arvo jokaiselle vastaukselle, lisää se CSP-otsikkoon muodossa 'nonce-...' ja stubin <script>-tagiin. Tämä on joustavin vaihtoehto dynaamisille sivuille.
2. Tiiviste (hash). Lisää stubin tarkan sisällön SHA-256-tiiviste direktiiviin script-src. Tämä toimii hyvin staattisille sivustoille, mutta mikä tahansa muutos stubiin, vaikka välilyönti, rikkoo sen.
3. Stubin isännöinti itse ulkoisena tiedostona omalla verkkotunnuksellasi, jonka 'self' kattaa. Tämä vaatii huolellisuutta, jotta se latautuu riittävän aikaisin.

Vältä 'unsafe-inline'-arvoa oikotienä. Se sallii jokaisen inline-skriptin, mikä poistaa suuren osan CSP:n tarjoamasta suojasta.

Noncet ja skriptit, jotka CMP injektoi

CMP, joka estää skriptejä suostumukseen asti, toimii usein pidättämällä ne ja injektoimalla ne myöhemmin. Noncepohjaisessa CSP:ssä myös nämä injektoidut skriptit on sallittava. Kaksi yleistä lähestymistapaa:

• Noncen välittäminen. CMP lukee noncen omasta skriptitagistaan ja lisää sen jokaiseen injektoimaansa skriptiin. Tarkista, tukeeko CMP:si tätä.
• 'strict-dynamic'. Tämä avainsana käskee tukevia selaimia luottamaan skripteihin, jotka jo luotettu skripti on ladannut. Se helpottaa elämää tagienhallinnan ja skriptejä injektoivien CMP:iden kanssa, mutta se tarkoittaa myös, että mikä tahansa luottamasi skripti voi ladata muita, joten luota harkiten.

Tagienhallinta herättää saman kysymyksen. Jos lataat mainos- ja analytiikkatagit tagienhallinnan kautta, noudata sen dokumentaatiota nonceista ja varmista, että CMP ja tagienhallinta käyttävät yhdenmukaista lähestymistapaa.

Mainostagit vaikeuttavat CSP:tä

Ohjelmallinen mainonta lataa skriptejä ja kehyksiä monista verkkotunnuksista, ja luettelo muuttuu kysyntäkumppanien vaihtuessa. Julkaisijat tekevät yleensä jommankumman valinnan:

• Tiukka CSP sivuilla, joilla ei ole ohjelmallisia mainoksia, ja laajempi käytäntö siellä, missä mainokset toimivat.
• Käytäntö, joka keskittyy direktiiveihin, jotka pysyvät hallittavina, kuten frame-ancestors, object-src 'none' ja base-uri, kun taas skriptilähteet pysyvät laajempina.

Kummassakin tapauksessa CMP:n tulisi olla nimenomaisessa sallittujen luettelossa, ei vain jokerimerkin kattama, jotta CSP-muutos ei koskaan hiljaa poista banneria käytöstä.

Ota käyttöön report-only-tilassa

Käytä ensin otsikkoa Content-Security-Policy-Report-Only. Selain raportoi rikkomukset estämättä mitään, joten näet, mitä uusi käytäntö rikkoisi.

1. Ota käytäntö käyttöön report-only-tilassa raportointipäätepisteen kanssa.
2. Lataa sivuja puhtaissa selainprofiileissa ja käy läpi koko suostumuskulku: ensimmäinen käynti, hyväksy kaikki, hylkää kaikki, mukautettu valinta, peruutus.
3. Tarkista rikkomusraportit ja selaimen konsoli estettyjen CMP-resurssien varalta.
4. Säädä käytäntöä ja siirry sitten valvontaan.
5. Pidä raportointi päällä valvonnan jälkeenkin regressioiden havaitsemiseksi.

CSP-ristiriidan oireet

• Banneri ei koskaan ilmesty, ja konsolissa on CSP-rikkomus CMP-skriptistä.
• Banneri ilmestyy, mutta ilman tyylejä, koska style-src estää sen CSS:n.
• Valintoja ei tallenneta, koska connect-src estää suostumuksen kirjauskutsun.
• Mainokset tai analytiikka eivät koskaan lataudu suostumuksen jälkeen, koska injektoiduilta skripteiltä puuttuu nonce.
• __tcfapi on määrittelemätön, koska inline-stub estettiin.

Keskeiset opit

• Tarkista CMP:llesi script-src, connect-src, style-src, img-src ja frame-src.
• Salli inline-stub noncella tai tiivisteellä, älä 'unsafe-inline'-arvolla.
• Varmista, että suostumuksen jälkeen injektoidut skriptit saavat noncen tai ne kattaa 'strict-dynamic'.
• Testaa jokainen suostumuspolku report-only-tilassa ennen valvonnan käyttöönottoa.
• Pidä CMP nimenomaisesti sallittujen luettelossa, jotta CSP-muutokset eivät voi poistaa sitä käytöstä.