Dy shtresa sigurie që duhet të bien dakord

Një Content Security Policy (CSP) i tregon shfletuesit nga cilat burime mund të ngarkojë një faqe skripte, stile, imazhe, frame dhe kërkesa rrjeti. Një platformë e menaxhimit të pëlqimit bën punën e kundërt: vendos cilat nga ato skripte lejohen të ekzekutohen sipas zgjedhjes së përdoruesit. Kur konfigurohen veçmas, ato përplasen. CMP-ja nuk ngarkohet sepse CSP e bllokon, ose CSP lehtësohet aq shumë për të pranuar CMP-në dhe etiketat e reklamave sa nuk mbron më asgjë.

Ky udhëzues shpjegon cilat direktiva CSP i duhen zakonisht një CMP-je, si ndërveprojnë nonce-t me injektimin e skripteve dhe si t'i zbatoni ndryshimet pa prishur banerin.

Çfarë i duhet zakonisht një CMP-je nga CSP

Kërkesat e sakta varen nga furnitori, ndaj nisuni gjithmonë nga dokumentacioni i vetë CMP-së suaj. Në përgjithësi, kontrolloni këto direktiva:

• script-src — domeni nga ngarkohet skripti i CMP-së, plus çdo skedar tjetër skripti që ngarkon.
• connect-src — pikat fundore që CMP-ja i thërret me fetch ose XHR, si ato të konfigurimit, listës së furnitorëve, gjeolokacionit dhe regjistrimit të pëlqimit.
• style-src — domeni i fletës së stilit, dhe ndoshta stilet inline nëse CMP-ja injekton një element <style> ose vendos atribute stili.
• img-src — logot, ikonat dhe çdo piksel pa gjurmim që përdor CMP-ja.
• font-src — nëse baneri ngarkon shkronjat e veta.
• frame-src — nëse CMP-ja përdor iframe, për shembull për ndarjen e pëlqimit mes domeneve.

Në sajtet me TCF, mbani mend që CMP-ja krijon edhe një frame lokalizues me emrin __tcfapiLocator në faqe. Ai frame krijohet pa burim të largët, ndaj zakonisht nuk ka nevojë për hyrje në frame-src, por vlen ta konfirmoni gjatë testimit.

Problemi i stub-it inline

Shumica e CMP-ve ju kërkojnë të vendosni një skript të vogël inline — stub-in — në head të faqes, që skriptet e tjera të mund të vënë thirrje në radhë para se të ngarkohet CMP-ja kryesore. Një CSP e rreptë i bllokon skriptet inline nëse nuk i lejoni shprehimisht. Keni tri mundësi:

1. Një nonce. Gjeneroni një vlerë të rastësishme për çdo përgjigje, shtojeni në kokën CSP si 'nonce-...' dhe në etiketën <script> të stub-it. Kjo është mundësia më fleksibile për faqe dinamike.
2. Një hash. Shtoni hash-in SHA-256 të përmbajtjes së saktë të stub-it te script-src. Funksionon mirë për sajte statike, por çdo ndryshim në stub, edhe në hapësira, e prish.
3. Vetëpritja e stub-it si skedar i jashtëm në domenin tuaj, i mbuluar nga 'self'. Kërkon kujdes që të ngarkohet mjaftueshëm herët.

Shmangni 'unsafe-inline' si shkurtore. Ai lejon çdo skript inline, çka heq një pjesë të madhe të mbrojtjes që ofron CSP.

Nonce-t dhe skriptet që injekton CMP-ja

Një CMP që i bllokon skriptet deri te pëlqimi shpesh punon duke i mbajtur ato dhe duke i injektuar më vonë. Nën një CSP të bazuar në nonce, edhe ato skripte të injektuara duhet të lejohen. Ka dy qasje të zakonshme:

• Përhapja e nonce-s. CMP-ja e lexon nonce-n nga etiketa e vet e skriptit dhe e shton te çdo skript që injekton. Kontrolloni nëse CMP-ja juaj e mbështet këtë.
• 'strict-dynamic'. Kjo fjalë kyçe u thotë shfletuesve që e mbështesin t'u besojnë skripteve të ngarkuara nga një skript tashmë i besuar. Ia thjeshton jetën me menaxherët e etiketave dhe CMP-të që injektojnë skripte, por do të thotë edhe që çdo skript që besoni mund të ngarkojë të tjera, ndaj besoni me kujdes.

Menaxherët e etiketave ngrenë të njëjtën pyetje. Nëse i ngarkoni etiketat e reklamave dhe të analitikës përmes një menaxheri etiketash, ndiqni dokumentacionin e tij për nonce-t dhe sigurohuni që CMP-ja dhe menaxheri i etiketave përdorin një qasje të qëndrueshme.

Etiketat e reklamave e bëjnë CSP-në më të vështirë

Reklamimi programatik ngarkon skripte dhe frame nga shumë domene, dhe lista ndryshon kur ndryshojnë partnerët e kërkesës. Botuesit zakonisht bëjnë një nga dy zgjedhjet:

• Një CSP e rreptë në faqet pa reklama programatike, dhe një politikë më e gjerë aty ku funksionojnë reklamat.
• Një politikë e përqendruar te direktivat që mbeten të menaxhueshme, si frame-ancestors, object-src 'none' dhe base-uri, ndërsa burimet e skripteve mbeten më të gjera.

Në të dyja rastet, CMP-ja duhet të jetë në listën e lejimit të shprehur, jo e mbuluar vetëm nga një wildcard, që një ndryshim i CSP-së të mos e çaktivizojë kurrë banerin në heshtje.

Vëreni në punë me modalitetin vetëm-raportim

Përdorni së pari kokën Content-Security-Policy-Report-Only. Shfletuesi raporton shkeljet pa bllokuar asgjë, kështu që mund të shihni çfarë do të prishte një politikë e re.

1. Vendoseni politikën në modalitetin vetëm-raportim me një pikë fundore raportimi.
2. Ngarkoni faqe në profile të pastra shfletuesi dhe kaloni nëpër rrjedhën e plotë të pëlqimit: vizita e parë, prano të gjitha, refuzo të gjitha, zgjedhje e personalizuar, tërheqje.
3. Shqyrtoni raportet e shkeljeve dhe konsolën e shfletuesit për burime të bllokuara të CMP-së.
4. Rregulloni politikën, pastaj kaloni në zbatim.
5. Mbajeni raportimin të aktivizuar edhe pas zbatimit për të kapur regresionet.

Simptomat e një konflikti CSP

• Baneri nuk shfaqet kurrë, dhe konsola tregon një shkelje CSP për skriptin e CMP-së.
• Baneri shfaqet por pa stil, sepse style-src ia bllokon CSS-in.
• Zgjedhjet nuk ruhen, sepse connect-src e bllokon thirrjen e regjistrimit të pëlqimit.
• Reklamat ose analitika nuk ngarkohen kurrë pas pëlqimit, sepse skripteve të injektuara u mungon një nonce.
• __tcfapi është i papërcaktuar, sepse stub-i inline u bllokua.

Pikat kryesore

• Kontrolloni script-src, connect-src, style-src, img-src dhe frame-src për CMP-në tuaj.
• Lejoni stub-in inline me nonce ose hash, jo me 'unsafe-inline'.
• Sigurohuni që skriptet e injektuara pas pëlqimit marrin një nonce ose mbulohen nga 'strict-dynamic'.
• Testoni çdo shteg pëlqimi në modalitetin vetëm-raportim para zbatimit.
• Mbajeni CMP-në në listën e lejimit shprehimisht, që ndryshimet e CSP-së të mos mund ta çaktivizojnë.