Politique de sécurité du contenu

La politique de sécurité du contenu (CSP) est un mécanisme de sécurité imposé par le navigateur qui contrôle quelles ressources externes telles que les scripts, styles, images, polices, cadres et plus encore sont autorisées à se charger sur votre Knowledge base site. Lorsque CSP est activé dans Document360, un directeur de politique de sécurité de contenu est intégré dans la source de la page de votre site, limitant le chargement des ressources uniquement aux domaines que vous configurez explicitement. Cela aide à protéger votre base de connaissances contre des vulnérabilités web courantes telles que le Cross-Site Scripting (XSS), le clickjacking et les attaques d'injection de données.

Pourquoi avez-vous besoin de CSP

Sans CSP, les navigateurs permettent à n'importe quelle ressource de se charger sur votre page — y compris des scripts, images et cadres provenant de domaines que vous n'aviez pas prévu d'autoriser. Cela crée des ouvertures pour :

• Scripting inter-site (XSS) : Attaquants injectant des scripts malveillants qui volent des jetons de session ou manipulent le contenu des pages.

• Clickjacking : Votre base de connaissances intégrée à l'intérieur d'un iframe invisible sur un site malveillant, trompant les utilisateurs pour obtenir des clics involontaires.

• Injection de données : Scripts tiers non autorisés exfiltrant silencieusement les données ou analyses des utilisateurs.

CSP vous permet de définir une liste de permis de domaines de confiance pour chaque type de ressource. Le navigateur l'applique automatiquement, aucun changement de code d'application n'est nécessaire.

Quand utiliser CSP ?

Le CSP est le plus précieux lorsque votre base de connaissances intègre du contenu tiers (vidéos, widgets de discussion, analyses), utilise du HTML personnalisé ou des scripts en ligne, est déployé dans un environnement d'entreprise sensible à la conformité ou d'entreprise, ou doit être protégé contre toute possibilité d'être encadré par des sites externes.

Comment fonctionne le CSP dans Document360

Document360 implémente CSP via un métaélément intégré dans la source de la page de votre site, plutôt que via un en-tête de réponse HTTP. Cela signifie :

• Toutes les règles CSP sont appliquées au niveau de la page via une <meta http-equiv="Content-Security-Policy"> balise.

• Si vous validez le CSP en inspectant l'en-tête de réponse HTTP, il apparaîtra absent et c'est un comportement attendu.

• Pour confirmer que le CSP est actif, faites un clic droit sur votre site de la Base de connaissances, sélectionnez Voir la source de la page, et recherchez « Content-Security-Policy ».

Pourquoi cette approche méta ?

Les en-têtes de réponse HTTP nécessitent une configuration côté serveur. Document360 utilise un méta-élément pour que vous puissiez configurer le CSP entièrement depuis l'interface des paramètres sans aucun changement d'infrastructure. La protection de sécurité est équivalente pour la grande majorité des directives, à l'exception des ancêtres des cadres, qui ne sont pris en charge que via des en-têtes HTTP dans certains navigateurs. Document360 gère cela automatiquement.

Activation de la politique de sécurité du contenu

1. Naviguez dans Paramètres () > Knowledge base site > Security.

2. Activez la fonction Activation de la politique de sécurité du contenu.

3. Configurez les groupes de directives requis. Vous pouvez trouver les champs sources suivants :
   a. Politique du code
   b. Contrôle des ressources
   c. Intégration et sécurité
   d. Rapport

4. Cliquez sur Enregistrer.

NOTE

Lorsque le CSP est activé, assurez-vous que le placeholder d'attribut nonce est ajouté à toutes les sections de scripts HTML personnalisés. Exemple :

<script nonce="{{Document360-Nonce}}">

NOTE

• La limite de caractères pour chaque champ est de 5000.

• Utilisez des virgules (,) pour séparer plusieurs domaines.

• Conservez les URL dans le format suivant : https://example.com.

• Les configurations CSP existantes restent conservées lors de l'activation et de l'activation du CSP.

Groupes directifs CSP

Les paramètres du CSP sont organisés en quatre groupes logiques. Chaque groupe contient des directives spécifiques contrôlant différents types de ressources. Tous les champs acceptent les URL de domaine séparées par virgules dans le format  https://example.com.

1. Politique de code

Ce groupe régit les sources d'où le code et les ressources de style sont chargées. Il constitue la base de votre configuration CSP ; la directive source par défaut sert de solution de secours pour tout type de ressource qui n'a pas de règle plus spécifique définie.

2. Contrôle des ressources

Ce groupe contrôle quels domaines externes sont autorisés à fournir des ressources médias et de données telles que des images, des polices, des appels API et des scripts de travailleurs en arrière-plan sur votre site de base de connaissances.

3. Intégration et sécurité

Ce groupe contrôle la manière dont votre Knowledge Base intègre le contenu externe et comment il peut lui-même être intégré sur d'autres sites web. Il est particulièrement important pour prévenir les attaques de clickjacking et gérer le contenu tiers tel que les vidéos, widgets et portails.

4. Déclaration

Le groupe Reporting vous permet de surveiller en pratique votre CSP en demandant aux navigateurs d'envoyer des rapports de violation à un point de terminaison désigné chaque fois qu'une ressource est bloquée par votre politique. C'est essentiel pour identifier les mauvaises configurations et les tentatives d'attaque potentielles sans perturber votre site.

NOTE

Assurez-vous que les URL de terminaison saisies dans les champs de Rapport sont valides et accessibles publiquement avant de les sauvegarder. Le point de terminaison du rapport doit également accepter les requêtes POST et répondre par un code d'état 2xx.

Protection X-Frame

L'option de protection X-Frame est disponible en même temps que les paramètres CSP sur la page Sécurité. Lorsqu'elle est activée, elle ajoute un en-tête de réponse X-Frame-Options : SAMEORIGIN à vos pages de la Base de connaissances, empêchant leur chargement dans un iframe sur tout domaine externe.

Cela offre une protection contre le clickjacking pour les navigateurs et outils traitant les en-têtes HTTP plutôt que le méta-balise CSP. C'est un contrôle plus simple et plus brutal que les ancêtres des trames. Il ne permet pas d'autoriser des domaines de confiance spécifiques

NOTE

Les options X-Frame et la frame-ancestors directive CSP régissent toutes deux le comportement d'intégration des trames. Si vous configurez les deux, assurez-vous qu'elles sont cohérentes pour éviter les règles conflictuelles.

Par exemple, n'activez pas la protection contre les trames X tout en ajoutant un domaine externe aux ancêtres des trames - l'en-tête X-Frame supplantera la directive CSP dans les navigateurs qui prennent en charge les deux.

Cas d'utilisation pour la politique de sécurité du contenu

Vidéos intégrées

Si vos articles incluent des vidéos de YouTube ou Vimeo, utilisez la directive source Frame pour n'autoriser que ces domaines de confiance.

• Ajouter à la source du cadre : https://www.youtube.com, https://player.vimeo.com

• Cela garantit que les médias intégrés se chargent correctement tout en bloquant le contenu iframe non autorisé.

Outils d'analyse et de retour d'information tiers

Si votre base de connaissances utilise Google Analytics, Mixpanel ou un widget de retours, ajoutez leurs domaines de script et de collecte de données au code source Script et au code source Connect.

• Exemple de source du script : https://www.google-analytics.com, https://cdn.mixpanel.com

• Exemple de connexion source : https://api.mixpanel.com

Widgets de chat en direct

Les widgets de chat comme Intercom ou Zendesk nécessitent généralement des permissions sur plusieurs directives car ils chargent des scripts, passent des appels API et servent leur propre interface utilisateur.

• Source du scénario : https://widget.intercom.io, https://js.intercomcdn.com

• Source du lien : https://api.intercom.io, https://nexus-websocket-a.intercom.io

• Source de l'image : https://static.intercomassets.com

Polices personnalisées

Google Fonts et Adobe Typekit se chargent depuis deux domaines différents - l'un pour la feuille de style et l'autre pour les fichiers de polices eux-mêmes. Les deux doivent être listés.

• Style source : https://fonts.googleapis.com

• Source : https://fonts.gstatic.com

Intégrer votre base de connaissances dans un portail client

Si vous devez afficher votre base de connaissances dans un iframe au sein de votre propre produit ou application SaaS, utilisez la directive Frame ancestors pour autoriser ce domaine spécifique.

• Exemple des ancêtres du cadre : https://app.yourcompany.com

• Définir les ancêtres du cadre sur « aucun » bloque tout le cadrage externe. Ne modifiez cela que si vous avez une exigence d'intégration légitime.

HTML personnalisé et scripts en ligne

Si vos articles ou votre thème incluent des sections HTML personnalisées avec des balises <script> en ligne, ces scripts seront bloqués par un CSP strict sauf s'ils portent un attribut nonce. Utilisez le placeholder nonce Document360 :

<script nonce="{{Document360-Nonce}}"> 

  // Your custom inline script 

</script> 

Le {{Document360-Nonce}} placeholder est remplacé au moment du rendu par une valeur unique par requête qui correspond au nonce indiqué dans le CSP. Cela permet au script en ligne de confiance de s'exécuter sans avoir à affaiblir votre politique avec « unsafe-inline ».

Environnements renforcés par la conformité et la sécurité

Les équipes opérant sous des cadres tels que SOC 2, ISO 27001 ou HIPAA nécessitent souvent une politique de chargement de ressources documentée. CSP fournit une version imposée par machine de cette politique. Les directives de rapport vous fournissent également une trace d'audit de toute tentative de violation de politique.

Meilleures pratiques

Commencez par un par défaut restrictif

Définissez d'abord la source par défaut sur « self ». Cela crée une base de base sécurisée, seules les ressources de votre propre domaine sont autorisées sauf si elles sont explicitement autorisées ailleurs. Ajoutez des domaines spécifiques dans les champs ciblés plutôt que d'élargir la source par défaut.

Utilisez des directives spécifiques au lieu de listes larges d'autorisations

Plutôt que d'ajouter de nombreux domaines à la source par défaut, utilisez les champs ciblés : source de script, source de trame, source de connexion, etc. Cela facilite la maintenance de la politique et réduit la surexposition accidentelle.

Évitez les jokers

Utiliser *. example.com permet n'importe quel sous-domaine de ce domaine, y compris ceux que vous ne contrôlez pas ou qui pourraient être compromis. N'utilisez des sous-domaines jokers que lorsque vous possédez tous les sous-domaines de ce domaine et que vous n'avez pas d'alternative. N'utilisez jamais un « bare » (autoriser tout) dans une directive.

Utilisez le reporting avant d'appliquer

Configurez d'abord le point de terminaison de signalement afin de pouvoir surveiller les ressources bloquées avant que la politique n'affecte vos lecteurs. Examinez les rapports de violation pendant plusieurs jours ou semaines avant de resserrer la politique.

Utilisez nonce pour les scripts en ligne personnalisés

Utilisez toujours le {{Document360-Nonce}} Placeholder dans les sections de scripts HTML personnalisés. Cela permet aux scripts en ligne de confiance de s'exécuter en toute sécurité sans utiliser le « unsafe-inline », ce qui compromettrait toute votre politique de script.

Gardez les réglages des images alignés

Si la protection X-Frame et les ancêtres des images sont tous deux configurés, assurez-vous qu'ils suivent le même comportement prévu. Des réglages mal alignés peuvent provoquer un blocage inattendu de l'iframe ou permettre un cadrage lorsque vous vouliez le bloquer.

Examen trimestriel

Les outils tiers modifient les domaines CDN au fil du temps. Réévaluez les paramètres de votre CSP après tout changement d'intégration et selon un calendrier régulier (au moins trimestriel) pour détecter les modifications qui auraient pu briser silencieusement le contenu intégré.

Tester votre politique de sécurité de contenu

Après avoir configuré et enregistré vos paramètres CSP, vérifiez que la politique fonctionne comme prévu en utilisant l'une des méthodes suivantes.

Méthode 1 : Via la source de la page

• Ouvrez votre site de base de connaissances dans un navigateur.

• Faites un clic droit n'importe où sur la page et sélectionnez Voir la source de la page.

• Utilisez Ctrl+F (Windows) ou Cmd+F (Mac) et cherchez « Content-Security-Policy ».

• Si elle est détectée, la configuration complète du CSP apparaîtra à côté de ce terme, confirmant qu'elle est active.

Méthode 2 : Via les outils de développement de navigateurs

1. Ouvrez les outils développeurs de votre navigateur (F12 ou faites un clic droit > Inspecter).

2. Naviguez jusqu'à l'onglet Réseau .

3. Visitez votre base de connaissances et sélectionnez n'importe quelle page demandée.

4. Vérifiez le HTML de la page pour la méta-balise CSP.

Méthode 3 : Via des outils en ligne

Vous pouvez également utiliser des outils externes comme securityheaders.com pour analyser la configuration de sécurité de votre site. Gardez à l'esprit que puisque Document360 utilise un métaélément plutôt qu'un en-tête de réponse, certains outils peuvent signaler CSP comme absent au niveau de l'en-tête, ce qui est attendu.

Dépannage

Étape 1 : Lire l'erreur de la console du navigateur

Lorsque CSP bloque une ressource, le navigateur enregistre une erreur spécifique dans la console développeur (F12 > onglet Console). Le message d'erreur indique exactement ce qui a été bloqué et quelle directive a été violée.

Par exemple : Refusé de charger le script 'https://cdn.example.com/widget.js' car il viole la directive CSP suivante : «script-src 'self' ». Cette erreur vous invite à ajouter https://cdn.example.com au champ source du script. Lisez le domaine à partir du message d'erreur et ajoutez-le au champ de directive correspondant dans les paramètres de Document360.

Étape 2 : Identifier la bonne directive

Associez le type de ressource dans l'erreur console au champ de directive correct :

Problèmes courants

La vidéo montre « Ce contenu est bloqué » dans un article mais pas dans un autre

Le domaine qui sert la vidéo ne figure pas dans votre liste d'attribution source d'images, ou le domaine diffère selon les types d'intégration (par exemple, https://www.youtube.com pour les embeds standards versus https://www.youtube-nocookie.com pour les embeds renforcées par la confidentialité). Ajoutez les deux à la source de frame.

Une police personnalisée s'affiche incorrectement ou revient à la police système

Les fournisseurs de polices utilisent généralement deux domaines différents - un pour la feuille de style CSS et un pour les fichiers de polices eux-mêmes. Les deux doivent être listés. Pour Google Fonts, ajoutez https://fonts.googleapis.com à la source de style et https://fonts.gstatic.com à la source de police.

Le widget de chat se charge mais ne fonctionne pas

Les widgets de chat chargent souvent des scripts, font des appels API et chargent des images depuis plusieurs domaines. Vérifiez la console du navigateur pour toutes les requêtes bloquées – il peut y en avoir plusieurs. Ajoutez tous les domaines requis aux champs de directives appropriés (source de script, source de connexion, source d'image).

La soumission du formulaire est bloquée

Si un formulaire de votre base de connaissances est soumis à un service externe, ajoutez le domaine de ce service au champ d'action du formulaire.

Les signalements de violations n'arrivent pas au point de terminaison du Signalement

Vérifiez que :

• L'URL du point de terminaison est accessible publiquement (pas derrière un VPN ou un pare-feu).

• Le point de terminaison accepte les requêtes POST et retourne une réponse 2xx.

• Le point de terminaison prend en charge le format de requête Content-Type : application/csp-report.

• Si vous utilisez la directive Report to, le groupe de rapports nommé est correctement configuré dans votre infrastructure.

L'outil de validation CSP signale CSP comme manquant

Document360 implémente CSP via un métaélément dans la source de la page, et non via un en-tête de réponse HTTP. Les outils qui ne vérifient que les en-têtes de réponse signaleront CSP comme manquant. Pour confirmer que CSP est activé, consultez la source de la page et recherchez Content-Security-Policy.

Différences entre navigateurs

La plupart des navigateurs modernes (Chrome, Firefox, Edge, Safari) prennent en charge l'élément méta CSP. Différences connues à surveiller :

• Frame-ancestors est ignoré lorsqu'il est délivré via un métaélément dans certaines anciennes versions du navigateur. Si la protection contre l'embedding de trame est critique, activez également la protection X-Frame.

• Safari peut gérer certaines directives CSP différemment de Chrome et Firefox. Testez votre configuration dans Safari si vos utilisateurs sont sur des appareils Apple.

• Les navigateurs très anciens (Internet Explorer 11 et versions inférieures) ne prennent pas en charge CSP. Si vous avez des utilisateurs IE11, CSP sera ignoré silencieusement.

NOTE

Les projets de la Base de Connaissances Privée ne peuvent pas être intégrés dans les iframes. Les cookies d'authentification ne sont pas correctement configurés dans les iframes, ce qui provoque des tentatives répétées de connexion et des erreurs de redirection. Si vous devez intégrer la Base de Connaissances dans une autre application, utilisez plutôt un Knowledge base widget .

{ 
"csp-report": 
{"document-uri": "https://docs.yourcompany.com/article", 
"violated-directive": "script-src 'self'", 
"blocked-uri": "https://cdn.example.com/widget.js", 
"original-policy": "default-src 'self'; script-src 'self'"} 
}