Consent banner-ът е блокиран от CSP

Защо това е важно

Строгият CSP е добра практика за сигурност, но ако блокира самото CMP, сайтът може тихо да загуби целия си consent слой в продукция.

Как да го проверите ръчно

1. Отворете DevTools конзолата и търсете CSP нарушения около CMP assets.
2. Проверете дали banner script-ът, CSS, iframe или API endpoints се блокират.
3. Сравнете поведението на CSP локално и в продукция, ако проблемът се появява само в продукция.

Типични причини

• CMP домейните не са позволени в script-src, frame-src или connect-src правилата.
• Nonce- или hash-базираните CSP правила не покриват inline bootstrap кода на CMP.
• Deploy е променил CSP headers без да валидира отново CMP dependencies.

Корекция в GTM

1. Не разчитайте на GTM като workaround, ако самите CMP assets се блокират от CSP.
2. Прегледайте дали GTM-инжектираните CMP fallback-и нарушават същите CSP правила.
3. Тествайте отново след обновяване на CSP headers в продукция.

Корекция в WordPress или CMP плъгини

1. Прегледайте security плъгини, hosting headers и CDN правила, които инжектират CSP.
2. Whitelist-нете само CMP домейните, които реално се използват от banner конфигурацията.
3. Тествайте отново с изключен browser cache след промени по headers.

Обща корекция за разработчици

1. Whitelist-нете само минимално необходимите CMP origins за scripts, frames и API calls.
2. Предпочитайте таргетирани CSP updates вместо да отслабвате цялата policy.
3. Версионирайте CSP правилата и тествайте banner-а отново при всяка промяна.

Как да потвърдите, че корекцията работи

• Потвърдете, че CSP грешките, свързани с CMP assets, изчезват.
• Потвърдете, че banner-ът се render-ва нормално и приема user interaction.
• Пуснете нов scan и проверете, че banner issue-то изчезва.