Dalawang Layer ng Seguridad na Dapat Magkasundo

Sinasabi ng Content Security Policy (CSP) sa browser kung saang mga pinagmulan maaaring mag-load ang isang pahina ng mga script, style, larawan, frame at network request. Kabaligtaran ang trabaho ng consent management platform: nagpapasya ito kung aling mga script ang pinapayagang tumakbo batay sa pagpili ng user. Kapag magkahiwalay ang pagkaka-configure ng dalawa, nagbabanggaan sila. Nabibigo ang CMP na mag-load dahil hinaharang ito ng CSP, o sobrang niluwagan ang CSP para sa CMP at mga ad tag kaya wala na itong pinoprotektahan.

Ipinapaliwanag ng gabay na ito kung anong mga CSP directive ang karaniwang kailangan ng isang CMP, paano nakikipag-ugnayan ang mga nonce sa script injection, at paano mag-roll out ng mga pagbabago nang hindi sinisira ang iyong banner.

Ano ang Karaniwang Kailangan ng CMP sa CSP

Nakasalalay sa vendor ang eksaktong mga kinakailangan, kaya laging magsimula sa sariling dokumentasyon ng iyong CMP. Sa pangkalahatan, suriin ang mga directive na ito:

• script-src — ang domain kung saan nilo-load ang CMP script, kasama ang anumang karagdagang script file na nilo-load nito.
• connect-src — mga endpoint na tinatawag ng CMP gamit ang fetch o XHR, gaya ng configuration, listahan ng vendor, geolocation at mga endpoint ng consent logging.
• style-src — ang domain ng stylesheet, at posibleng mga inline style kung nag-i-inject ang CMP ng <style> element o nagtatakda ng mga style attribute.
• img-src — mga logo, icon at anumang pixel na walang tracking na ginagamit ng CMP.
• font-src — kung naglo-load ang banner ng sarili nitong mga font.
• frame-src — kung gumagamit ang CMP ng mga iframe, halimbawa para sa cross-domain na pagbabahagi ng pahintulot.

Sa mga TCF site, tandaan na gumagawa rin ang CMP ng locator frame na pinangalanang __tcfapiLocator sa pahina. Ginagawa ang frame na iyon nang walang remote na source, kaya karaniwang hindi ito nangangailangan ng frame-src entry, ngunit sulit itong kumpirmahin sa pagsubok.

Ang Problema ng Inline Stub

Karamihan sa mga CMP ay humihiling na maglagay ka ng maliit na inline script — ang stub — sa head ng pahina, para makapag-queue ng mga tawag ang ibang script bago mag-load ang pangunahing CMP. Hinaharang ng mahigpit na CSP ang mga inline script maliban kung tahasan mo silang pinapayagan. May tatlo kang opsyon:

1. Isang nonce. Bumuo ng random na halaga bawat response, idagdag ito sa CSP header bilang 'nonce-...' at sa <script> tag ng stub. Ito ang pinakaflexible na opsyon para sa mga dynamic na pahina.
2. Isang hash. Idagdag ang SHA-256 hash ng eksaktong nilalaman ng stub sa script-src. Gumagana ito nang maayos sa mga static na site, ngunit sinisira ito ng anumang pagbabago sa stub, kahit whitespace.
3. Self-hosting ng stub bilang external na file sa sarili mong domain, na sakop ng 'self'. Kailangan dito ng pag-iingat para manatiling maaga ang pag-load nito.

Iwasan ang 'unsafe-inline' bilang shortcut. Pinapayagan nito ang bawat inline script, na nag-aalis ng malaking bahagi ng proteksyong ibinibigay ng CSP.

Mga Nonce at mga Script na Ini-inject ng CMP

Ang CMP na humaharang ng mga script hangga't walang pahintulot ay madalas na gumagana sa pamamagitan ng pagpigil sa mga ito at pag-inject sa mga ito sa kalaunan. Sa ilalim ng nonce-based na CSP, kailangan ding payagan ang mga ini-inject na script na iyon. May dalawang karaniwang pamamaraan:

• Nonce propagation. Binabasa ng CMP ang nonce mula sa sarili nitong script tag at idinaragdag ito sa bawat script na ini-inject nito. Tingnan kung sinusuportahan ito ng iyong CMP.
• 'strict-dynamic'. Sinasabi ng keyword na ito sa mga sumusuportang browser na pagkatiwalaan ang mga script na nilo-load ng isang script na pinagkakatiwalaan na. Pinapadali nito ang buhay sa mga tag manager at CMP na nag-i-inject ng mga script, ngunit nangangahulugan din itong ang anumang scriptong pinagkakatiwalaan mo ay maaaring mag-load ng iba, kaya mag-ingat sa pagtitiwala.

Itinataas ng mga tag manager ang parehong tanong. Kung naglo-load ka ng mga ad at analytics tag sa pamamagitan ng tag manager, sundin ang dokumentasyon nito tungkol sa mga nonce at tiyaking pare-pareho ang pamamaraang ginagamit ng CMP at ng tag manager.

Pinahihirap ng mga Ad Tag ang CSP

Naglo-load ang programmatic advertising ng mga script at frame mula sa maraming domain, at nagbabago ang listahan habang nagbabago ang mga demand partner. Karaniwang isa sa dalawa ang pinipili ng mga publisher:

• Isang mahigpit na CSP sa mga pahinang walang programmatic na ad, at mas malawak na patakaran kung saan tumatakbo ang mga ad.
• Isang patakarang nakatuon sa mga directive na nananatiling mapapamahalaan, gaya ng frame-ancestors, object-src 'none' at base-uri, habang nananatiling mas malawak ang mga source ng script.

Sa alinmang paraan, dapat nasa tahasang allow list ang CMP, hindi lang sakop ng wildcard, para hindi kailanman tahimik na madi-disable ng pagbabago sa CSP ang banner.

I-roll Out Gamit ang Report-Only Mode

Gamitin muna ang Content-Security-Policy-Report-Only header. Iniuulat ng browser ang mga paglabag nang walang hinaharang, kaya makikita mo kung ano ang masisira ng bagong patakaran.

1. I-deploy ang patakaran sa report-only mode na may reporting endpoint.
2. Mag-load ng mga pahina sa malilinis na browser profile at daanan ang buong daloy ng pahintulot: unang pagbisita, accept all, reject all, custom na pagpili, pag-withdraw.
3. Suriin ang mga ulat ng paglabag at ang browser console para sa mga na-block na resource ng CMP.
4. Ayusin ang patakaran, pagkatapos ay lumipat sa enforcement.
5. Panatilihing naka-enable ang reporting pagkatapos ng enforcement para mahuli ang mga regression.

Mga Sintomas ng CSP Conflict

• Hindi kailanman lumilitaw ang banner, at nagpapakita ang console ng CSP violation para sa CMP script.
• Lumilitaw ang banner ngunit walang style, dahil hinaharang ng style-src ang CSS nito.
• Hindi nase-save ang mga pagpili, dahil hinaharang ng connect-src ang consent logging call.
• Hindi kailanman naglo-load ang mga ad o analytics pagkatapos ng pahintulot, dahil walang nonce ang mga ini-inject na script.
• Undefined ang __tcfapi, dahil na-block ang inline stub.

Mga Pangunahing Punto

• Suriin ang script-src, connect-src, style-src, img-src at frame-src para sa iyong CMP.
• Payagan ang inline stub gamit ang nonce o hash, hindi ang 'unsafe-inline'.
• Tiyaking tumatanggap ng nonce ang mga script na ini-inject pagkatapos ng pahintulot o sakop ng 'strict-dynamic'.
• Subukan ang bawat landas ng pahintulot sa report-only mode bago mag-enforce.
• Panatilihing tahasang naka-allow-list ang CMP para hindi ito ma-disable ng mga pagbabago sa CSP.