Posted by Nous voyons régulièrement, en épluchant les discussions sur le net, que les concepts de CORS et CSP sont confondus par beaucoup d’entre nous. Ce sont deux notions de la sécurité qu’il est bien de savoir départager, mais aussi de combiner.
CSP (Content Security Policy) et CORS (Cross Origin Resource Sharing) sont deux stratégies de sécurité utilisées par les applications Web permettant de contrôler qui peut accéder à mes ressources et attester que ma page Web n’a pas été altérée par une ressource non autorisée.
Qu’est-ce que le CORS ?
C’est un mécanisme de sécurité, défini dans l’en-tête de réponse d’une requête HTTP retournée par le serveur, qui permet à ce dernier de dicter quels domaines sont autorisés à recevoir une donnée demandée. Il effectue donc un filtrage sur les applications/domaines l’appelant. Le comportement par défaut pour un serveur hébergé sur un domaine A est de rejeter toute demande provenant d’un autre domaine que le sien. En paramétrant le CORS, il est possible de signifier à l’appelant B qu’il est autorisé à accéder à une ressource provenant du domaine A, mais de refuser à C cette même demande.
Ce paramètre n’est pas à prendre à la légère, même dans le cadre d’un développement, car il autorise finalement n’importe qui à accéder aux ressources du serveur A. Faites donc attention si votre serveur héberge des données sensibles.
L’en-tête HTTP est défini comme suit : Access-Control-Allow-Origin : *
Le wildcard (*) signifie que n’importe qui peut charger une ressource du serveur A depuis un domaine B, C, D, etc.
L’en-tête HTTP est défini comme suit : Access-Control-Allow-Origin : mon.domaine.com
Access-Control-Allow-Origin : mon.domaineB.com mon.domaineC.com
Mais l’en-tête peut aussi contenir une liste de domaines autorisés.
Qu’est ce que le CSP ?
Le CSP est une approche de la sécurité différente, mais qui a aussi pour but de protéger les ressources d’un domaine particulier. L’objectif de cette politique est de se protéger contre les attaques de type XSS (Cross-Site-Scripting) en définissant quels scripts sont approuvés ou non. Lorsqu’un navigateur tente par exemple d’exécuter un script provenant d’un domaine distant, comme jquery.min.js depuis le CDN de Google par exemple, les règles définies dans l’en-tête de réponse CSP peuvent désigner ou non ajax.googleapis.com comme source fiable.
L’en-tête de réponse Content-Security-Policypeut être défini comme suit et restreindre des éléments tels que :
default-src : limite qui s’applique quel que soit le type de ressource.script-src: limite les scripts en ligne pouvant être exécutés.style-src: empêche l’application des styles en ligne.media-src: empêche le chargement des fichiers audio et multimédia.img-src: empêche le chargement des images.- et bien d’autres sur cette page de développeur Mozilla.
Pour mettre tout cela en image, nous allons montrer plusieurs scénarios et pour chacun d’eux nous allons depuis notre ordinateur charger une page Web depuis le site x.domain-A.net et le site malveillant x.malicious.net va intercepter chacune de nos réponses et tenter d’injecter un script Javascript malveillant qui devrait s’exécuter sur notre navigateur une fois la page retournée.
Dans cet exemple, aucune règle n’a été définie concernant le CSP. Le site malveillant intercepte donc la page retournée par le serveur et y injecte un script que nous allons exécuter malgré nous sans même nous en rendre compte.
Dans le cas où la règle CSP a été définie pour autoriser les scripts provenant du domaine googleapis.com (ainsi que les fichiers locaux du serveur, mais rien d’autre), alors la page est toujours interceptée, mais le script est ignoré, protégeant ainsi l’utilisateur.
Bien qu’il existe pléthore de mécanismes pour protéger nos ressources sur le Web, celles que nous venons de voir sont deux stratégies souvent confondues, mais pourtant différentes et complémentaires, qu’il est facile d’implémenter pour protéger à moindre coût nos serveurs et nos services hébergés tels que des APIs.