Pour faire face à la montée des menaces sur leurs utilisateurs, les navigateurs se sont au fil du temps enrichis de mécanismes qui visent à contrôler le contenu d'une page Web. En particulier, il faut évoquer :
- Single Origin Policy (SOP), désormais modulée par Cross-Origin Resource Sharing (CORS), dont l'objet est de contrôler le contenu qui peut accéder à celui servi ;
- Content Sharing Policy (CSP), dont l'objet est de contrôler le contenu auquel celui servi peut accéder.
Du fait qu'il ne fallait pas casser le Web en instaurant ces mécanismes, ces derniers ne changent pas grand-chose pour le développeur d'une application Web standard, au sens d'un ensemble de pages servies par un même serveur, qui n'affichent jamais que du contenu qui en provient.
C'est tout particulièrement vrai pour CSP, qui ne vient pas limiter des pratiques - par exemple faire figurer du script inline dans une balise
<script> - tant que le développeur ne met pas lui-même en place CSP en accompagnant ses pages d'un header Content-Security-Policy.
Il est va autrement pour SOP et CORS, qui d'emblée limitent des pratiques. En particulier, il est impossible depuis le script d'une page Web de formuler une requête via l'API Fetch pour récupérer du contenu dont l'origine, entendue comme la composition du nom de domaine et du numéro de port, n'est pas celle de la page en question.
Or cela peut être nécessaire, comme on va l'illustrer en prenant le cas d'une application Web où l'utilisateur accède à une page servie par un serveur Node.js (module http) à l'écoute sur le port 3000 de localhost, dans laquelle un script récupère du contenu en appelant un service exposé par un autre serveur Node.js (module http) à l'écoute sur le port 3001 du même localhost.
Continuer la lecture de "CORS avec Node.js"
