Les attaques cross-site-scripting (XSS) exploitent la confiance que les navigateurs ont dans le contenu reçu des serveurs. Des scripts malveillants peuvent être exécutés sur des navigateurs de victimes car ceux-ci font aveuglément confiance au serveur qui leur envoie des données même quand celles-ci ne proviennent pas de là où elles semblent venir[12].
CSP permet aux administrateurs système de réduire ou éliminer les moyens de réaliser les attaques XSS en permettant de spécifier les domaines autorisés à fournir des scripts pour la page visitée. Les navigateurs compatibles avec CSP n'exécutent alors des scripts ne provenant que d'une origine autorisée par les règles CSP et ignorent ceux qui ne sont pas autorisés. On peut alors bloquer les domaines non autorisés, les scripts inline (inclus dans une page HTML) ou associés à des évènements via les attributs HTML dédiés.
Le niveau de protection le plus élevé consisterait alors à n'autoriser l'exécution d'aucun script.
CSP permet également de forcer l'utilisation de HTTPS pour certains domaines, ainsi que l'utilisation de cookies sécurisés, ne pouvant être envoyés que via HTTPS, afin d'améliorer la sécurité. Outre l'utilisation détournée de CSP pour cette fonction, l'utilisation de l'en-tête Strict-Transport-Security permet de s'assurer que les navigateurs utilisent obligatoirement des connexions chiffrées en TLS (HTTPS).
CSP peut être activé de deux manières différentes par un serveur web :
- L'en-tête (header) HTTP
Content-Security-Policy est ajouté dans les réponses du serveur.
- Une balise
<meta> est ajoutée dans le code HTML afin de définir la règle. Par exemple : <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
L'en-tête est alors suivie d'une chaîne de caractères contenant la liste des règles constituant la règle CSP : Content-Security-Policy: règle. Une règle CSP permet de spécifier des valeurs afin de contrôler les ressources que le navigateur est autorisé à charger pour la page donnée.
Une règle est définie par une série de directives qui décrivent chacune un comportement attendu pour un certain type de contenu ou pour l'ensemble des requêtes.
Trois directives courantes sont :
default-src : qui s'applique aux ressources pour lesquelles aucune règle n'est définie[13].script-src : qui définit des sources valides pour des scripts JavaScript[14].style-src : qui définit des sources valides pour des feuilles de style CSS.
- On souhaite que tout le contenu du site soit fourni par la même origine (on exclut les sous-domaines) :
Content-Security-Policy: default-src 'self';
- On souhaite que tout le contenu du site soit fourni par le site lui-même ou par les sous-domaines de
source-sure.example.net : Content-Security-Policy: default-src 'self' *.source-sure.example.net;
- On souhaite que toutes les données soient transmises en HTTPS depuis un domaine précis :
Content-Security-Policy: default-src https://confidentiel.example.net Cette règle force l'utilisation de HTTPS et exclut tout usage de contenu ne venant pas de https://confidentiel.example.net.
Afin de tester le déploiement de CSP sur un serveur, on peut le configurer pour rapporter les violations de règle sans pour autant appliquer réellement la règle. De telle façon, on ne bloque pas les usages du site en récupérant les rapports de violation de la règle en phase de test.
Pour cela, il suffit d'utiliser l'en-tête Content-Security-Policy-Report-Only (CSPRO)[15] de la même façon que CSP :
Content-Security-Policy-Report-Only: règle
Si les en-têtes HTTP Content-Security-Policy-Report-Only et Content-Security-Policy sont tous deux présents dans une réponse du serveur, les deux règles seront respectées, ce qui permet de tester une nouvelle règle tout en gardant l'usage de règles préexistantes. Les règles de CSP sont appliquées tandis que celles de CSPRO génèrent des rapports mais ne sont pas appliquées.
Si jamais l'exécution d'un script ou une ressource demandée viole la Politique, le navigateur émettra une requête POST aux URL spécifiées dans report-uri, qui contiendra les détails de la violation. Il faut donc que la directive report-uri soit spécifiée avec au moins une URL valide.
Par exemple :
Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi
Les rapports d'erreur CSP sont des structures JSON standards qui peuvent être capturées tout aussi bien par l'API de l'application utilisée ou bien par des serveurs publiques de rapport d'erreur CSP.
