CSP blokuoja sutikimo bannerį

Kodėl tai svarbu

Griežtas CSP yra gera saugumo higiena, bet jei jis blokuoja patį CMP, svetainė produkcijoje gali tyliai prarasti visą sutikimo sluoksnį.

Kaip tai patikrinti rankiniu būdu

1. Atidarykite DevTools konsolę ir ieškokite CSP pažeidimų aplink CMP assetus.
2. Patikrinkite, ar blokuojami bannerio scriptas, CSS, iframe ar API endpointai.
3. Palyginkite CSP elgseną lokaliai ir produkcijoje, jei problema atsiranda tik produkcijoje.

Tipinės priežastys

• CMP domenai nėra leidžiami script-src, frame-src ar connect-src taisyklėse.
• Nonce ar hash pagrindu paremtos CSP taisyklės neapima CMP inline bootstrap kodo.
• Deploy pakeitė CSP headerius nepervaliduodamas CMP priklausomybių.

Pataisa GTM

1. Nesiremkite GTM kaip workaround, jei patys CMP assetai blokuojami CSP.
2. Peržiūrėkite, ar GTM injektuoti CMP fallbackai nepažeidžia tų pačių CSP taisyklių.
3. Pakartotinai testuokite po CSP headerių atnaujinimo produkcijoje.

Pataisa WordPress ar CMP įskiepiuose

1. Peržiūrėkite security įskiepius, hosting headerius ir CDN taisykles, kurios injektuoja CSP.
2. Į whitelist įtraukite tik tas CMP domenų kilmes, kurias iš tiesų naudoja bannerio konfigūracija.
3. Pakartotinai testuokite su išjungtu naršyklės cache po headerių pakeitimų.

Bendra kūrėjų pataisa

1. Į whitelist įtraukite tik minimaliai būtinas CMP kilmes scripts, frameams ir API kvietimams.
2. Rinkitės tikslingus CSP atnaujinimus vietoje visos politikos susilpninimo.
3. Versijuokite CSP taisykles ir bannerį testuokite po kiekvieno pakeitimo.

Kaip patvirtinti, kad pataisa veikia

• Patvirtinkite, kad su CMP assetais susijusios CSP klaidos išnyko.
• Patvirtinkite, kad banneris renderinamas normaliai ir priima vartotojo sąveiką.
• Paleiskite naują scan ir patikrinkite, kad bannerio issue išnyksta.