Samtyckesbannern blockeras av CSP

Varför det här är viktigt

En strikt CSP är god säkerhetshygien, men om den blockerar själva CMP:n kan webbplatsen tyst förlora hela sitt samtyckeslager i produktion.

Så verifierar du manuellt

1. Öppna DevTools-konsolen och leta efter CSP-överträdelser kring CMP-tillgångar.
2. Kontrollera om bannerns script, CSS, iframe eller API-endpoints blockeras.
3. Jämför CSP-beteendet lokalt och i produktion om problemet bara uppstår i produktion.

Typiska orsaker

• CMP-domäner är inte tillåtna i script-src-, frame-src- eller connect-src-regler.
• Nonce- eller hash-baserade CSP-regler täcker inte CMP:ns inline-bootstrap-kod.
• En deploy ändrade CSP-headern utan att CMP-beroenden validerades igen.

Åtgärd i GTM

1. Förlita er inte på GTM som workaround om själva CMP-tillgångarna blockeras av CSP.
2. Granska om GTM-injicerade CMP-fallbackar bryter mot samma CSP-regler.
3. Testa igen efter att CSP-headern uppdaterats i produktion.

Åtgärd i WordPress eller CMP-pluginer

1. Granska säkerhetspluginer, hostingheaders och CDN-regler som injicerar CSP.
2. Vitlista bara de CMP-domäner som bannerkonfigurationen faktiskt använder.
3. Testa igen med avstängd webbläsarcache efter headerändringar.

Generell utvecklaråtgärd

1. Vitlista endast de CMP-origins som minimalt krävs för skript, frames och API-anrop.
2. Föredra riktade CSP-uppdateringar i stället för att försvaga hela policyn.
3. Versionshantera CSP-regler och testa bannern igen vid varje ändring.

Så bekräftar du att åtgärden fungerar

• Bekräfta att CSP-fel kopplade till CMP-tillgångar försvinner.
• Bekräfta att bannern renderas normalt och accepterar användarinteraktion.
• Kör en ny skanning och kontrollera att bannerproblemet försvinner.