La sécurité d'un site web ne se résume pas aux pare-feu et aux mots de passe robustes. Une grande partie des attaques réelles se produisent directement dans le navigateur du visiteur, où des scripts injectés peuvent voler des données ou détourner une session.
Cela inclut également la protection des données sur Internet et la mise en place d’une défense contre les codes malveillants ou autres attaques par injection de code.
Cet article se concentre sur une mesure de sécurité, la politique de sécurité du contenu.
La politique de sécurité du contenu est principalement conçue pour le côté client des applications Web. La mesure de sécurité offre une protection significative aux navigateurs modernes contre les contenus malveillants.
Continuez à lire pour en savoir plus sur cette fonctionnalité de sécurité et comment la configurer.
Quelle est la politique de sécurité du contenu du site Web ?
Une politique de sécurité du contenu (CSP) est une norme de sécurité. Elle protège les sites web et les applications contre diverses attaques, comme les attaques de type cross-site scripting (XSS). La CSP est un en-tête de réponse HTTP qui renforce la sécurité des pages web sur les principaux navigateurs modernes.
L'en-tête de la politique de sécurité du contenu fonctionne en limitant les sources de contenu (comme les scripts et les images) qu'une page Web peut charger et à partir de laquelle elle peut être chargée.
Si vous implémentez l'en-tête de réponse HTTP Content Security Policy (CSP) sur un navigateur qui ne le prend pas en charge, celui-ci l'ignore. De plus, il applique par défaut la politique d'origine identique (une autre forme de protection contre les codes malveillants). Cependant, le navigateur reste compatible avec un serveur prenant en charge la CSP, et inversement.
Notez que CSP est une couche de sécurité supplémentaire contre différents types de vulnérabilités. Le mot-clé ici est « supplémentaire ». En d’autres termes, vous devez toujours protéger votre page Web à l’aide d’autres mesures de sécurité.
Il convient également de préciser que le CSP n'empêche pas votre page web d'être attaquée. Il détecte efficacement ces attaques et réduit considérablement le risque d'exploitation.
Importance de la politique de sécurité du contenu du site Web
L'en-tête de politique de sécurité du contenu (CSP) vous permet de contrôler les sources de contenu que votre site peut charger. La mise en œuvre de la CSP est possible sur tout type de site web, qu'il s'agisse d'un site e-commerce ou d'un blog.
Cela aide à :
Atténuer les attaques XSS
Nous avons déjà mentionné que CSP pourrait aider à atténuer les attaques XSS. Mais de quoi s’agit-il exactement et comment le CSP peut-il vous aider ?
Une vulnérabilité XSS permet à un attaquant d'injecter du code malveillant dans une page web. Une telle vulnérabilité expose votre site web à des attaques telles que le vol de données et le défaçage de site. Figurant depuis des années dans le Top 10 des risques liés aux applications web de l'OWASP, la vulnérabilité XSS reste l'un des types de vulnérabilités les plus fréquemment signalés dans les extensions WordPress.
CSP protège contre les attaques XSS en limitant les scripts en ligne. Cela empêche également votre page Web de charger des scripts distants, c'est-à-dire des scripts provenant de serveurs arbitraires.
CSP protège également votre site Web contre les attaques XSS en contrôlant la soumission des formulaires HTML. Ainsi, même si les visiteurs partagent les détails de leur carte de crédit pour acheter un produit ou remplissent des certificats d'adhésion LLC en ligne, leurs données restent protégées. Fondamentalement, CSP restreint la destination des données de ces formulaires. De plus, CSP restreint la balise d'objet HTML.
CSP atténue également les attaques XSS en permettant aux administrateurs de serveur de spécifier les noms de domaine que le navigateur doit considérer comme sources valides de scripts exécutables.
En fin de compte, grâce au CSP, les attaquants ne peuvent pas injecter de scripts malveillants.
Empêcher le détournement de clics
Bien que CSP ait été initialement introduit pour atténuer la surface d’attaque des attaques XSS, il a également été développé pour offrir une protection contre les attaques d’applications Web telles que le détournement de clics.
Dans le détournement de clic, l'attaquant incite un utilisateur à cliquer sur un bouton ou un lien sur une page Web déguisé en autre chose.
À moins de faire appel à des sociétés spécialisées dans la protection contre l'usurpation d'identité, vous risquez d'être victime de détournement de clic. Vous ne vous en rendrez compte qu'une fois les dégâts importants causés, comme des transferts d'argent frauduleux ou des achats en ligne illégaux.
Auparavant, l'en-tête X-Frame-Options constituait la norme en matière de protection contre le détournement de clic. La directive frame-ancestors de la CSP (introduite dans la CSP niveau 2 et intégrée à la version préliminaire actuelle du niveau 3) remplit la même fonction avec une plus grande flexibilité, et les navigateurs modernes lui donnent la priorité. De nombreux sites envoient encore les deux en-têtes pour les navigateurs plus anciens.
La norme CSP de niveau 2 contient une directive anti-clickjacking ` frame-ancestors` . Cette directive spécifie l'URL de la page parente autorisée à intégrer une page web dans une frame, une iFrame ou un objet de la ressource actuelle.
En résumé, vous limitez les pages qui peuvent intégrer la page actuelle dans un cadre. Voici un exemple d'utilisation de la directive ` frame-ancestors` :
politique de sécurité du contenu : ancêtres du cadre 'self' '\*.internxt.com' ;
Vous pouvez également utiliser la directive frame-ancestors avec les directives default-src et script-src pour réduire les attaques de type clickjacking.
Quelles autres attaques le CSP prévient-il ?
La CSP peut également imposer le protocole HTTPS. Dans votre politique, n'indiquez que les sources https:// et ajoutez la directive upgrade-insecure-requests afin que le navigateur charge automatiquement les ressources http:// restantes via HTTPS. (L'ancienne directive block-all-mixed-content est désormais obsolète, car les navigateurs bloquent ou mettent à niveau automatiquement le contenu mixte.)
Les autres vulnérabilités que vous pouvez résoudre avec CSP incluent :
- Code Javascript dynamique utilisant eval()
- Javascript en ligne non attribué dans tags
- CSS dynamique utilisant CSSStylesheet.insertRule()
- Instructions CSS en ligne non attribuées dans tags
Comment configurer une politique de sécurité du contenu
La mise en place de CSP est une étape essentielle dans la protection de votre application web. Vous pouvez mettre en place une défense CSP pour votre site Web de trois manières.
En-tête de politique de sécurité du contenu
Cette méthode implique l’envoi de l’en-tête de réponse HTTP content-security-policy depuis le serveur Web. Par exemple;
Politique de sécurité du contenu : …
Assurez-vous de configurer l'en-tête dans toutes les réponses HTTP.
Balises méta Contenu-Sécurité-Politique
Si vous ne pouvez pas utiliser l'en-tête de réponse HTTP CSP, vous pouvez tout de même configurer la CSP pour votre site web à l'aide de l'élément meta « HTTP-equiv » dans le fichier HTML. Voici à quoi ressemble une ligne de balise meta CSP :
Cette méthode présente des limitations quant aux fonctionnalités CSP utilisables. Par exemple, la protection contre le framing et le point de terminaison de journalisation des violations CSP ne sont pas disponibles.
En-tête Content-Security-Policy-Report-Only
Cet en-tête indique au navigateur de signaler les violations de politique sans bloquer aucune activité. Les rapports sont envoyés au point de terminaison défini par la directive `report-to` (associée à un en-tête `Reporting-Endpoints`). L'ancienne directive `report-uri` est obsolète, mais reste largement prise en charge ; de nombreux sites utilisent donc les deux pour le moment. Par exemple :
content-security-policy-report-only: script-src 'self';
rapport à csp-reporting-endpoint
La principale différence entre cet en-tête et l'en-tête de réponse HTTP CSP standard réside dans le fait que le premier n'applique pas la politique. Cependant, les navigateurs autorisent les sites à utiliser à la fois l'en-tête « content-security-policy » et l'en-tête « content-security-policy-report-only ».
Détails de mise en œuvre
Vous devez déterminer les directives à inclure dans votre politique de sécurité. Les directives sont des règles qui régissent les types de contenu auxquels accèdent les navigateurs web des utilisateurs, tels que les images, les fichiers de script et les feuilles de style.
Cette étape précède la rédaction du contenu de votre site web et l'assurance de sa visibilité. Ces deux dernières actions sont relativement simples, même pour les débutants. La création de contenu est l'un des cas d'utilisation les plus courants de l'IA générative . Il vous suffit donc de fournir les indications nécessaires, et l'IA générera le contenu de qualité que vous recherchez.
Grâce aux nombreuses ressources et outils SEO gratuits disponibles, vous pouvez également effectuer vous-même tout le travail de référencement pour améliorer la visibilité de votre site. Toutefois, pour obtenir les meilleurs résultats, il est préférable de faire appel aux services d'une agence SEO spécialisée dans le secteur manufacturier, juridique ou SaaS, possédant une vaste expérience et une grande expertise.
En revanche, créer des règles spécifiques pour chaque domaine et sous-domaine de votre site Web est bien plus difficile pour un débutant. Vous commencez par découvrir les règles et les problèmes disponibles. Vous choisissez ensuite ce qui doit être inclus sur votre liste et prenez les mesures appropriées (si autorisé) ou non (si interdit). C'est pourquoi certains préfèrent embaucher des développeurs pour ce travail.
Mais si vous êtes prêt à relever le défi, examinons de plus près les directives CSP que nous avons mentionnées dans les sections précédentes pour vous aider à gérer cet aspect de votre site :
Récupérer les directives
Vous incluez des directives fetch dans le champ d'en-tête de votre réponse pour spécifier les emplacements auxquels votre navigateur peut faire confiance et à partir desquels charger les types de ressources. La plupart des directives de récupération reviennent à default-src. Cela signifie que si une directive fetch n'est pas répertoriée dans le champ d'en-tête de réponse, les valeurs de la directive sont extraites des directives par défaut.
Des exemples de directives de récupération incluent « child-src », « font-src » et « img-src ».
Directives sur les documents
Les directives de document dans le champ d'en-tête de votre réponse CSP indiquent au navigateur les propriétés des documents auxquels la stratégie s'applique.
Par exemple, la directive « base-URI » limite les URL utilisables par l’élément racine du document. Autre exemple : la directive « sandbox », qui restreint les actions possibles sur la page. Les directives de document ne se réfèrent pas aux directives « default-src » par défaut.
Directives de navigation
Les directives de navigation déterminent où un document peut envoyer des utilisateurs ou des données. Les principales sont « form-action », qui limite les URL auxquelles les formulaires peuvent soumettre des données, et « frame-ancestors », qui contrôle les sites autorisés à intégrer votre page. (La directive « navigate-to », proposée dans la spécification, a été abandonnée et n'a jamais été implémentée dans les navigateurs.)
Assurez-vous de mettre régulièrement à jour votre politique de sécurité pour garantir que votre site ne devienne pas vulnérable aux menaces émergentes.
Politique de test
CSP peut fonctionner sur un site Web s’il n’est pas configuré correctement. C'est là qu'interviennent les tests.
Le mode rapport uniquement est une méthode efficace pour tester si un CSP fonctionne correctement. Le mode Rapport uniquement fournit des informations sur le nombre de violations CSP qui se seraient produites si la stratégie avait été appliquée, mais ne bloque rien.
Cette méthode de test aide les propriétaires de sites Web à comprendre où leur politique risque d'échouer. En conséquence, ils peuvent l’ajuster en conséquence.
Divers outils permettent de tester la politique de sécurité du client (CSP) d'un site web en mode rapport uniquement. L'un des plus populaires est CSP Evaluator.
Cet outil vous permet de saisir une URL. L'outil vérifie ensuite si un en-tête CSP existe. Il indiquera également si le CSP est correctement configuré ou non. Dans le même temps, il analyse la politique, signale les problèmes potentiels et vous guide sur la manière de l'améliorer.
La capture d'écran suivante montre certaines des suggestions de l'outil :
Vous pouvez également utiliser des outils d'analyse comme MDN HTTP Observatory (successeur de Mozilla Observatory) ou CSP Tester. Leur fonctionnement est similaire à celui de CSP Evaluator : ils vérifient vos en-têtes, évaluent votre politique et proposent des améliorations.
Des extensions comme CSP Tester et CSP Debugger de Google peuvent également vous aider à tester vos CSP.
Ils suivent le contenu écrit et vidéo chargé sur une page web ainsi que ses sources, en signalant toute violation des règles de sécurité du contenu (CSP).
Ces extensions sont disponibles pour les navigateurs Chrome et Firefox. Ils peuvent être utilisés pour tester, déboguer et valider votre CSP sur votre site Web. Ils peuvent également générer des rapports sur l’efficacité (ou l’absence d’efficacité) des CSP.
Règles d'utilisation de CSP
CSP est un outil efficace pour minimiser les risques liés à la sécurité des applications web. Cependant, comme tout outil de sécurité, CSP a ses propres règles d'utilisation. Il est essentiel de les comprendre pour l'utiliser efficacement.
Voici donc quelques règles :
Utilisez une politique basée sur un nonce avec l'option « strict-dynamic ». Dans ce cas, seuls les scripts contenant le nonce (ou hachage) unique correct sont exécutés, et tous les scripts qu'ils chargent sont automatiquement considérés comme fiables. Cette configuration rend la politique stricte particulièrement adaptée aux sites utilisant des gestionnaires de balises ou chargeant des scripts dynamiquement, sans nécessiter la gestion d'une longue liste blanche de domaines.
Les scripts intégrés sont des scripts écrits directement dans le code HTML, au lieu d'être chargés depuis des fichiers externes. Conformément à une politique stricte, un script intégré ne s'exécute que s'il contient un nonce valide ou un hachage correspondant ; tout code injecté dépourvu de ces éléments est donc bloqué.
Cependant, l'utilisation de code en ligne est déconseillée. La directive `inline` permet d'intégrer des scripts et des styles directement dans votre code HTML. Cette pratique est risquée car elle permet aux pirates d'injecter du code malveillant dans votre contenu. Il est préférable d'utiliser les attributs `nonce-value` et `hash-value` pour autoriser les scripts et styles en ligne provenant de sources fiables.
N'utilisez pas non plus `eval()`. La directive `eval()` permet l'exécution de scripts générés dynamiquement. Elle peut contourner la CSP et exécuter du code arbitraire, ce qui représente un risque de sécurité important.
Si votre site Web s'appuie fortement sur des scripts et des styles en ligne ou sur des bibliothèques et des plugins tiers, vous aurez peut-être besoin d'aide pour implémenter CSP.
Vous pouvez utiliser un outil tel que Content Security Policy Builder pour vous aider à créer un CSP personnalisé qui prend en compte les besoins spécifiques de votre site Web et des bibliothèques et plugins tiers.
Ajout d'un CSP à un site WordPress
Sur WordPress, vous pouvez envoyer l'en-tête depuis votre serveur web (configuration Apache .htaccess ou Nginx), depuis un CDN comme Cloudflare via une règle d'en-tête de réponse, ou avec une extension de sécurité prenant en charge les en-têtes personnalisés. Quelle que soit la méthode choisie, gardez les points suivants à l'esprit :
- Démarrer en mode rapport uniquement. Les thèmes, les constructeurs de pages, les scripts d'analyse et de paiement proviennent de nombreuses sources, et une politique stricte peut perturber les processus de paiement ou les formulaires dès le premier jour.
- Attention à la mise en cache des pages. Le nonce doit être différent pour chaque réponse. Si un cache de page complète sert le même code HTML à tous, les nonces ne sont plus secrets ; il faut donc utiliser des hachages ou une liste blanche sur les pages mises en cache, ou générer les nonces au niveau du CDN.
- Avis après les mises à jour. Les nouveaux plugins et les intégrations tierces nécessitent souvent de nouvelles sources ; vérifiez donc vos rapports de violation après des modifications importantes.
Exemples de politiques de sécurité du contenu
CSP peut être mis en œuvre de différentes manières, en fonction des besoins spécifiques d'un site Web. Voici quelques exemples de politiques CSP pour vous aider à mieux comprendre :
- Pour configurer votre en-tête CSP pour autoriser les scripts, CSS, AJAX et images de l'origine actuelle sans charger d'autres ressources ;
Content-Security-Policy: default-src 'none' ; script-src 'self' ; connect-src 'self' ; img-src 'self' ; style-src 'self' ; frame-ancestors 'self' ; form-action 'self' ;
- Pour configurer une politique modérément stricte dans le champ d’en-tête de réponse ;
script-src 'nonce-r4nd0m' 'strict-dynamic' ;
object-src 'none' ; base-uri 'none' ;
- La configuration CSP pour la politique stricte de verrouillage ;
script-src 'nonce-r4nd0m'
object-src 'none' ; base-uri 'none' ;
Il est important de noter que si la mise en œuvre d'un CSP contribue à améliorer la sécurité de votre site web, elle doit être utilisée conjointement avec d'autres mesures de sécurité, telles que des protocoles d'authentification forts, des mises à jour logicielles régulières et l'enregistrement de domaine auprès de fournisseurs réputés, afin de garantir une protection complète contre les cybermenaces.
Vous pouvez en savoir plus sur les attributs occasionnels pour CSP sur MDN. Vous pouvez également apprendre de ce guide de référence.
En clôture
La sécurité sur le Web n’est pas une chose à prendre à la légère. Les gens peuvent perdre leur argent et faire face à des menaces (entre autres) de cyberattaques telles que les scripts intersites et le détournement de clics. Par conséquent, une politique de sécurité du contenu devrait constituer une couche de protection nécessaire pour toutes les applications Web.
Évaluer vos politiques de réponse aux incidents, y compris les systèmes dont vous disposez pour détecter les menaces de cybersécurité, comme les simulations de violation et d'attaque , et la manière dont vous les gérerez efficacement si elles surviennent.
Néanmoins, en ce qui concerne la sécurité, vous devez prendre des précautions lorsque vous utilisez Internet pour éviter de devenir la proie d'attaquants.
En vous familiarisant avec les différents types de politiques et de protocoles, vous pouvez mieux protéger non seulement votre site Web, mais également votre public qui aurait pu partager ses informations personnelles sur votre site.
