CSP blokira banner soglasja

Zakaj je to pomembno

Strog CSP je dobra varnostna praksa, vendar lahko spletno mesto tiho izgubi celoten sloj soglasja, če blokira sam CMP.

Kako to ročno preveriti

1. Odprite DevTools konzolo in poiščite CSP kršitve, povezane s CMP resursi.
2. Preverite, ali so blokirani banner script, CSS, iframe ali API endpointi.
3. Primerjajte CSP vedenje lokalno in v produkciji, če se težava pojavlja samo v produkciji.

Tipični vzroki

• CMP domene niso dovoljene v pravilih script-src, frame-src ali connect-src.
• Nonce ali hash osnovana CSP pravila ne pokrivajo inline bootstrap kode CMP-ja.
• Deploy je spremenil CSP headerje brez ponovne validacije CMP odvisnosti.

Popravek v GTM

1. Ne zanašajte se na GTM kot workaround, če CSP blokira same CMP asssete.
2. Preglejte, ali GTM-injicirani CMP fallbacki kršijo ista CSP pravila.
3. Ponovno testirajte po posodobitvi CSP headerjev v produkciji.

Popravek v WordPressu ali CMP vtičnikih

1. Preglejte security vtičnike, hosting headerje in CDN pravila, ki injicirajo CSP.
2. Allowlistajte samo tiste CMP domene, ki jih konfiguracija bannerja dejansko uporablja.
3. Po spremembah headerjev ponovno testirajte z izključenim browser cacheom.

Splošen developerski popravek

1. Allowlistajte le minimalno potrebne CMP origine za script, frame in API klice.
2. Raje izvajajte ciljne CSP spremembe kot oslabitev celotne politike.
3. Verzionirajte CSP pravila in po vsaki spremembi ponovno testirajte banner.

Kako potrditi, da popravek deluje

• Potrdite, da CSP napake povezane s CMP asseti izginejo.
• Potrdite, da se banner normalno renderira in sprejema uporabniške interakcije.
• Zaženite nov scan in preverite, da banner issue izgine.