Sécurité et Content Security Policy

La Content Security Policy

Le widget ne charge aucune police tierce, aucun pixel de suivi et n’exécute pas eval. Il définit ses styles avec des feuilles de style constructibles (adoptedStyleSheets) dans le shadow DOM ; elles ne sont pas couvertes par style-src. Vous n’avez donc besoin ni de unsafe-inline ni de unsafe-eval.

Avec les adresses reactive.chat :

Content-Security-Policy:
  script-src 'self' https://cdn.reactive.chat;
  connect-src 'self' wss://ws.reactive.chat https://ws.reactive.chat;
  img-src 'self' data: https:;

Avec un domaine personnalisé :

Content-Security-Policy:
  script-src 'self' https://chat.your-company.com;
  connect-src 'self' wss://chat.your-company.com https://chat.your-company.com;
  img-src 'self' data: https:;

Les différentes directives :

• script-src – l’emplacement de loader.js. Le noyau (core.<hash>.js) et les modules chargés ensuite (visites, texte de confidentialité, boutique) proviennent aussi de cet emplacement.
• connect-src avec wss:// – la connexion du chat.
• connect-src avec https:// – la même adresse une seconde fois : le repli HTTP, le formulaire hors ligne, les envois de fichiers, le texte de confidentialité et Smart Answer l’utilisent. Si cette directive manque, vous ne le remarquerez que dans les réseaux sans WebSocket ; aucune connexion n’y sera alors établie.
• img-src – les images du chat : logo et avatars (vos adresses https:// ou images data:), images de la carte promotionnelle et aperçus des pièces jointes (depuis l’adresse du chat). Si vous restreignez img-src, incluez au minimum l’adresse du chat et les hôtes des images de votre logo et de vos cartes. Le widget affiche une image bloquée comme une ligne de fichier, au lieu d’un aperçu.

Les navigateurs plus anciens sans feuilles de style constructibles (comme Safari avant 16.4) utilisent en repli un élément <style>, bloqué par un style-src strict. Le widget y fonctionne, mais sans styles.

Aucun script en ligne nécessaire

L’installation consiste uniquement en un <script src> avec des attributs. Vos propres appels (identify, track, open) doivent figurer dans vos fichiers de script ou dans un script en ligne avec un nonce :

<script nonce="R4nd0mN0nc3">
  ReactiveChat('identify', { userId: '4711', userHash: '…', exp: 1792503600 });
</script>

Un modèle sans script en ligne figure dans Identifier les visiteurs.

Subresource Integrity

loader.js ne possède aucun numéro de version dans son nom et est mis à jour en continu ; un attribut integrity arrêterait le chat à la prochaine mise à jour. Le noyau est chargé avec un hachage de contenu dans son nom (Architecture). Si votre politique exige SRI, distribuez vous-même loader.js et définissez data-rc-ws-url (Démarrage rapide), mais sa mise à jour relève alors aussi de votre responsabilité.

Isolation de votre page

• Shadow DOM fermé. Vos styles n’atteignent pas le widget et les siens n’atteignent pas votre page, même avec des réinitialisations globales.
• Aucun cookie. Le widget ne définit aucun cookie ; les identifiants sont conservés dans le stockage du navigateur, sans consentement uniquement dans sessionStorage (Intégration de la confidentialité).
• Aucun accès aux champs de formulaire. La lecture du texte de page pour l’assistant ne lit jamais les champs de saisie et ne s’exécute pas sur les pages comme account, checkout et cart. Vous excluez d’autres zones avec data-rc-private.
• Les données personnelles sont masquées deux fois : dans le navigateur avant l’envoi d’un message (numéros de carte avec vérification de Luhn, IBAN, e-mail, téléphone, numéros fiscaux), puis sur le serveur avant stockage. Les paramètres de requête sensibles (email, password, token, key, card…) sont supprimés des adresses transmises.
• Les liens et images des messages et cartes sont limités à https://; les liens javascript: et data: sont écartés.

Vérification de l’origine

La connexion du chat n’est acceptée que depuis les domaines indiqués dans le projet sous Origines autorisées (sous-domaines inclus). Une page tierce qui copie votre clé de site reçoit origin_denied. Si la liste est vide, aucune vérification n’a lieu ; saisissez donc toujours vos domaines. Détails dans Transport.

La clé de site elle-même n’est pas un secret ; elle figure dans le code source de chaque page.

Ce qui ne doit jamais figurer dans le navigateur

• le secret d’identité (pour userHash) – Identité
• le secret du point de terminaison des données clients rckd_… – Données clients
• le secret de signature des webhooks – Webhooks
• les clés d’API rc_live_… – API serveur
• la clé du proxy rcpx_… – Domaine personnalisé

Ni dans une application, un dépôt public ou l’adresse d’une page.

Protection contre les abus

Le serveur limite les connexions, trames et messages par connexion et par adresse, et bloque les violations répétées (fermeture 1008). Derrière votre propre proxy, il ne compte par adresse de visiteur que si la clé du proxy est correcte ; sinon, tous les visiteurs partagent l’adresse du proxy. Chiffres dans Limites et quotas.

Suite : Domaine personnalisé