CORS a été créé pour assouplir SOP (Same-origin policy). Ce mécanisme de sécurité permet à une origine A d’émettre une requête vers une origine B et de recevoir une réponse de cette origine B si A fait partie des origines autorisées par B. Si l’origine A n’est pas autorisée il y aura un message d’erreur « CORS Allow Origin Not Matching Origin ».
Pour ce faire il faut que l’origine B définisse les origines autorisées à recevoir des données de sa part en utilisant le header Access-Control-Allow-Origin.
Exemples :
Access-Control-Allow-Origin : *: Autorise toutes les origines.Access-Control-Allow-Origin : http://sitepartenaire.com: Autorise uniquement les requêtes provenant de sitepartenaire.com
A noter que les sous-domaines doivent être autorisés explicitement comme le sont les sites tiers.
Lorsque l’on souhaite utiliser un mécanisme d’authentification avec CORS il faut utiliser l’entête Access-Control-Allow-Credentials: true. Par exemple si vous souhaitez transmettre un cookie contenant un token d’authentification il faudra que le serveur soit configuré pour retourner cet entête. A noter que la wildcard Access-Control-Allow-Origin : * ne peut pas être utilisée avec cet entête et cela pour des raisons de sécurité.
Il faut être particulièrement vigilant lors de la mise en place de CORS. En effet une mauvaise configuration du serveur peut permettre à des origines non désirées d’échanger avec la votre et donc un attaquant pourrait parvenir à voler des données.
Enfin CORS ne protège pas des cross-site request forgery (CSRF) et il ne dispense pas bien sûr d’une sécurisation minutieuse du serveur Web. Si l’origine à qui on a fait confiance est vulnérable alors un attaquant pourrait s’en servir pour voler des données provenant de notre origine.
Sources :