Bannerul de consimțământ este blocat de CSP

De ce contează

O CSP strictă este o bună igienă de securitate, dar dacă blochează CMP-ul însuși, site-ul își poate pierde tăcut întregul strat de consimțământ în producție.

Cum verificați manual

1. Deschideți consola DevTools și căutați încălcări CSP legate de asset-urile CMP.
2. Verificați dacă scriptul bannerului, CSS-ul, iframe-ul sau endpoint-urile API sunt blocate.
3. Comparați comportamentul CSP dintre local și producție dacă problema apare doar în producție.

Cauze tipice

• Domeniile CMP nu sunt permise în script-src, frame-src sau connect-src.
• Regulile CSP bazate pe nonce sau hash nu acoperă codul inline de bootstrap al CMP.
• Un deployment a schimbat header-ele CSP fără să revalideze dependențele CMP.

Remediere în GTM

1. Nu vă bazați pe GTM ca workaround dacă asset-urile CMP sunt blocate chiar de CSP.
2. Revizuiți dacă fallback-urile CMP injectate prin GTM încalcă aceleași reguli CSP.
3. Retestați după actualizarea header-elor CSP în producție.

Remediere în WordPress sau pluginuri CMP

1. Verificați pluginurile de securitate, header-ele hostului și regulile CDN care injectează CSP.
2. Whitelistuiți doar domeniile CMP cu adevărat folosite de configurația bannerului.
3. Retestați după schimbarea header-elor cu cache-ul browserului dezactivat.

Remediere generică pentru dezvoltatori

1. Whitelistuiți doar originile CMP minim necesare pentru scripturi, frame-uri și apeluri API.
2. Preferați actualizări CSP țintite în locul relaxării întregii politici.
3. Versionați regulile CSP și retestați bannerul la fiecare schimbare.

Cum confirmați că remedierea funcționează

• Confirmați că dispar erorile CSP legate de asset-urile CMP.
• Confirmați că bannerul se randază normal și acceptă interacțiunea utilizatorului.
• Rulați o nouă scanare și verificați că issue-ul bannerului dispare.