Bannière de consentement bloquée par CSP

Pourquoi c'est important

Une CSP stricte est une bonne pratique de sécurité, mais si elle bloque la CMP elle-même, le site peut perdre silencieusement toute sa couche de consentement en production.

Comment vérifier manuellement

1. Ouvrez la console DevTools et cherchez des violations CSP liées aux assets CMP.
2. Vérifiez si le script de bannière, le CSS, l'iframe ou les endpoints API sont bloqués.
3. Comparez le comportement CSP local et production si le problème n'apparaît qu'en production.

Causes typiques

• Les domaines CMP ne sont pas autorisés dans script-src, frame-src ou connect-src.
• Les règles CSP basées sur nonce ou hash ne couvrent pas le code inline de bootstrap CMP.
• Un déploiement a modifié les headers CSP sans revalider les dépendances CMP.

Correction dans GTM

1. Ne comptez pas sur GTM comme contournement si les assets CMP eux-mêmes sont bloqués par CSP.
2. Vérifiez si des fallbacks CMP injectés via GTM violent les mêmes règles CSP.
3. Retestez après mise à jour des headers CSP en production.

Correction dans WordPress ou les plugins CMP

1. Vérifiez les plugins de sécurité, headers injectés par l'hébergeur et règles CDN qui ajoutent une CSP.
2. Autorisez uniquement les domaines CMP réellement utilisés par votre bannière.
3. Retestez après changement de headers avec le cache navigateur désactivé.

Correction générique côté développeur

1. Autorisez seulement les origines CMP minimales nécessaires pour scripts, frames et API.
2. Préférez des ajustements CSP ciblés plutôt qu'un assouplissement global de la politique.
3. Versionnez vos règles CSP et retestez la bannière à chaque modification.

Comment confirmer que la correction fonctionne

• Confirmez que les erreurs CSP liées aux assets CMP disparaissent.
• Confirmez que la bannière se rend normalement et accepte les interactions utilisateur.
• Lancez un nouveau scan et vérifiez que l'issue de bannière disparaît.