Si vous n’avez pas besoin de certains types de contenu pour une page ou pour l’ensemble du site Internet, vous pouvez alors entrer la valeur 'none' dans l’en-tête des directives correspondantes, vous spécifiez ainsi qu’aucune source ne peut être chargée du tout. Vous pouvez aussi utiliser la valeur 'self' pour spécifier que le navigateur ne peut charger que du contenu provenant de la même source. Les deux valeurs doivent toujours être écrites entre guillemets simples, sinon none et self seront interprétés comme des domaines.
Il existe différentes options d’en-tête pour définir une Content Security Policy :
- Content Security Policy
- X-Webkit CSP
- X-Content Security Policy
Tous les navigateurs ne supportent pas tous les noms. Cependant, le W3C (l’organisme de standardisation sur le Web) propose une Content-Security-Policy. Par conséquent, tous les navigateurs modernes se sont adaptés à ce standard de sécurité (les deux autres versions sont considérés comme obsolètes). Pour vous assurer d’atteindre le plus grand nombre possible d’internautes (même ceux dont la version du navigateur est dépassée) avec votre CSP, il est recommandé d’inclure tous les champs d’en-tête. Si un navigateur Web ne peut pas utiliser l’en-tête Content Security Policy, il l’ignorera simplement et affichera le site Web sans problème, cependant, la protection supplémentaire n’est pas fournie aux utilisateurs concernés.
Vous définissez habituellement les en-têtes HTTP à travers les pages pour l’ensemble de votre domaine. Pour les sous-répertoires, vous pouvez utiliser le fichier .htaccess. Vous utilisez ensuite le mécanisme de sécurité CSP pour définir des règles spéciales pour des sous-pages individuelles. Par exemple, si vous avez implémenté un bouton de médias sociaux sur une page mais pas sur la suivante, il est logique de n’autoriser l’accès qu’à la source externe sur la première page.
Les sources peuvent être saisies sous forme d’adresses, à leurs façons ou sous forme de Wildcard (Joker). Les entrées suivantes sont donc autorisées :
- script-src 'https://example.com:443' – Les scripts ne sont autorisés à partir de ce domaine que via HTTPS.
- script-src 'none' – Les scripts ne doivent pas être chargés.
- script-src 'self' – Les scripts peuvent être chargés depuis la même source que la page principale, mais pas depuis les sous-domaines.
- script-src https: – Les scripts peuvent être chargés à partir de n’importe quel domaine tant qu’il débute par HTTPS.
- script-src example.com – Les scripts peuvent être chargés à partir de ce domaine
- script-src *.example.com – Les scripts de ce domaine et de tous les sous-domaines sont autorisés.
- img-src data: – Les images peuvent être chargées via des URL de données
Une Content Security Policy stipule fondamentalement que les scripts ne peuvent être chargés qu’à partir de fichiers, et non directement à partir du code du site Web. Si vous voulez éviter cela, vous pouvez utiliser la commande script-src 'unsafe-inline'. Cependant, vous devez être conscient que cela crée à son tour une faille de sécurité. La norme de sécurité interdit aussi la fonction eval (). En fait, vous pouvez convertir le texte en code JavaScript avec cette commande, mais même ceci est un risque de sécurité. Si vous avez encore besoin de cette fonction, vous pouvez la réactiver avec script-src 'unsafe-eval'.