Documentation

ConsentLab + CSP

01 · Pourquoi

Une CSP stricte, sans unsafe-inline

Une Content-Security-Policy stricte est l’une des meilleures protections contre les attaques XSS : le navigateur n’exécute que les scripts et styles explicitement autorisés par votre politique, via un nonce généré par votre serveur à chaque requête.

Beaucoup d’outils tiers demandent d’ajouter 'unsafe-inline' à votre politique pour fonctionner. Ne le faites jamais : cela annule l’essentiel de la protection apportée par la CSP, pour tout votre site.

ConsentLab n’en a pas besoin : le widget récupère le nonce de votre page au chargement et l’applique automatiquement à tout ce qu’il injecte, ses styles et les scripts qu’il débloque après consentement.

02 · Intégration

Poser le nonce sur le loader

Recommandé : l’attribut nonce natif

Posez l’attribut nonce standard sur la balise du loader, comme pour n’importe quel script de votre page, avec la valeur générée par votre serveur à chaque requête (snippet à droite).

C’est tout : le widget lit le nonce de sa propre balise au démarrage et le propage à toutes ses injections. Aucun autre attribut, aucune configuration.

Alternative : data-cc-nonce (loader injecté dynamiquement)

Les navigateurs vident l’attribut nonce des éléments insérés dans le DOM (protection contre l’exfiltration). Si votre loader est injecté dynamiquement (tag manager, script d’init…), le widget ne peut pas relire le nonce natif : passez-le aussi via data-cc-nonce (snippet à droite).

data-cc-nonce est réservé à ce cas précis et doit être posé uniquement sur la balise du loader ConsentLab : le widget utilise le premier script[data-cc-nonce] du document. En intégration HTML classique, utilisez l’attribut nonce natif.

03 · Politique

La politique recommandée

Exemple de politique stricte compatible avec ConsentLab et vos autres scripts (colonne de droite).

Avec 'strict-dynamic', les scripts créés par notre loader nonced héritent de sa confiance (navigateurs modernes) : les scripts débloqués au consentement s’exécutent sans allowlister chaque domaine tiers.
Les styles injectés, eux, ont toujours besoin du nonce : 'strict-dynamic' ne s’applique qu’aux scripts. C’est pour cela que le widget propage nativement le nonce.
Sans 'strict-dynamic', ça fonctionne aussi : le widget pose le nonce partout où c’est nécessaire (styles et clones de scripts). Ajoutez alors les origines des scripts externes à script-src (section suivante).
Le https: en fin de script-src est un repli pour les navigateurs qui ne connaissent pas 'strict-dynamic' (il est ignoré par ceux qui le connaissent).

04 · Origines

Ce que la politique doit autoriser

connect-src https://api.consentlab.eu : le widget y charge sa configuration et enregistre les preuves de consentement. Si vous pointez vers une autre instance via data-cc-api, autorisez cette origine-là.
script-src https://cdn.consentlab.eu : uniquement si le loader vient du CDN et que votre politique n’utilise pas 'strict-dynamic' (le nonce sur la balise suffit sinon).
Les domaines des outils que vous débloquez au consentement (par exemple www.googletagmanager.com, *.google-analytics.com) dans script-src / connect-src, selon leur documentation, sauf si 'strict-dynamic' couvre déjà leurs scripts.

05 · Diagnostic

Deux symptômes, une même cause

Deux symptômes typiques quand le nonce n’atteint pas le widget : dans les deux cas, la console développeur (F12) affiche des violations CSP explicites (messages types à droite).

06 · FAQ

Nonce, meta tag et cas limites

Dois-je ajouter 'unsafe-inline' pour ConsentLab ?

Non, jamais. Le widget est conçu pour les politiques par nonce : posez le nonce sur la balise du loader et il est propagé à toutes les injections (styles et scripts). Ajouter 'unsafe-inline' affaiblirait la protection XSS de tout votre site.

Mon site n’a pas de CSP, dois-je faire quelque chose ?

Non. Sans nonce détecté, le support CSP du widget est totalement inactif : aucun attribut ajouté, aucun changement de comportement.

Pourquoi le nonce si j’utilise déjà 'strict-dynamic' ?

'strict-dynamic' ne couvre que les scripts : les styles injectés par le widget (bandeau, modale de préférences, murs de consentement) exigent toujours un nonce valide dans style-src. Et si votre politique n’utilise pas 'strict-dynamic', le nonce est aussi propagé aux scripts débloqués au consentement.

J’utilise un meta tag CSP, pas un header : compatible ?

Oui, le mécanisme est identique : le navigateur applique la politique de la balise <meta http-equiv> et le widget propage le nonce de la même façon. Le header HTTP reste recommandé (il couvre plus de directives et s’applique plus tôt).

Besoin d’aide sur votre politique CSP ?

Envoyez-nous votre header CSP et les violations console : notre équipe répond en moins de 24 h.

Retour à la documentation Contacter le support

La balise avec nonce

<script
  src="https://cdn.consentlab.eu/widget/v1/consentlab.min.js"
  data-cc-key="VOTRE_CLE_API"
  nonce="{NONCE}"
  defer
></script>

Loader injecté dynamiquement

// Uniquement si le loader est injecté dynamiquement.
const s = document.createElement('script');
s.src = 'https://cdn.consentlab.eu/widget/v1/consentlab.min.js';
s.defer = true;
s.dataset.ccKey = 'VOTRE_CLE_API';
s.dataset.ccNonce = nonce; // le nonce CSP de la page courante
s.nonce = nonce;           // requis pour exécuter le loader lui-même
document.head.appendChild(s);

Politique recommandée

Content-Security-Policy:
  script-src 'nonce-{NONCE}' 'strict-dynamic' https:;
  style-src 'nonce-{NONCE}';
  connect-src 'self' https://api.consentlab.eu;

Violation · styles

Refused to apply inline style because it violates the following
Content Security Policy directive: "style-src 'nonce-…'".

Violation · scripts

Refused to execute inline script because it violates the following
Content Security Policy directive: "script-src 'nonce-…'".