Samtykkebanner blokeres af CSP

Hvorfor det betyder noget

En streng CSP er god sikkerhedshygiejne, men hvis den blokerer selve CMP'en, kan websitet lydløst miste hele sit samtykkelag i produktion.

Sådan verificerer du manuelt

1. Åbn DevTools-konsollen og se efter CSP-overtrædelser omkring CMP-assets.
2. Kontrollér, om bannerets script, CSS, iframe eller API-endpoints blokeres.
3. Sammenlign CSP-adfærden lokalt og i produktion, hvis problemet kun opstår i produktion.

Typiske årsager

• CMP-domæner er ikke tilladt i script-src-, frame-src- eller connect-src-regler.
• Nonce- eller hash-baserede CSP-regler dækker ikke CMP'ens inline-bootstrap-kode.
• En deploy ændrede CSP-headeren uden at CMP-afhængigheder blev valideret igen.

Rettelse i GTM

1. Stol ikke på GTM som workaround, hvis selve CMP-assets blokeres af CSP.
2. Gennemgå om GTM-injicerede CMP-fallbacks bryder de samme CSP-regler.
3. Test igen efter opdatering af CSP-headeren i produktion.

Rettelse i WordPress eller CMP-plugins

1. Gennemgå sikkerhedsplugins, hostingheaders og CDN-regler, der injicerer CSP.
2. Whitelist kun de CMP-domæner, som bannerkonfigurationen faktisk bruger.
3. Test igen med slået browsercache fra efter headerændringer.

Generel udviklerrettelse

1. Whitelist kun de CMP-origins, der er minimalt nødvendige for scripts, frames og API-kald.
2. Foretræk målrettede CSP-opdateringer frem for at svække hele politikken.
3. Versionsstyr CSP-regler og test banneret igen ved hver ændring.

Sådan bekræfter du, at rettelsen virker

• Bekræft, at CSP-fejl knyttet til CMP-assets forsvinder.
• Bekræft, at banneret renderes normalt og accepterer brugerinteraktion.
• Kør en ny scanning, og kontrollér at bannerproblemet forsvinder.