Discussion :

[adrienfehr]

Bonjour,

Une petite question par rapport aux bonnes pratiques avec le CORS et les headers Access-Control-Allow-.

Si l'on considère ce context:

• Une application vueJS qui doit appeler une Rest API
• Si cette Rest Api n'implemente pas ces headers:
  
  

alors le browser (chrome, Firefox ...) va générer une exception Cross-Origin Request Blocked dés lors que le service rest sera appelé.




On peut ajouter ces headers (Access-Control-Allow-...) dans les microservices afin de ne plus avoir ces problèmes de Cross Origin (ces services seront tôt ou tard appelés par la UI [VueJS]). On peut même faire mieux en ayant un API gateway : La front end appelera uniquement un rest service et ce même rest service appèlera les autres microservices (mais ce n'est pas le topic dans ce post)


En fait cette erreur (CORS) va seulement apparaitre quand on va appeler le service rest à partir du Browser (par exemple à partir d'une application vue JS).

Si un hacker crée un service rest externe à votre application il peut appeler votre microservice (qui n'a pas ces headers) mais n'aura pas cet exception Cross Origin car il l'appelera à partir d'un service Rest et non d'un browser.

Quelle est ici la bonne pratique : dois je porter une attention particulière à ces headers (est-ce dangereux de les setter à Access-Control-Allow-Origin=* ou à son nom de domaine) ?

Merci pour votre aide

[thelvin]

Hello,

oui, eh bien, il faut vérifier.

Le hacker dont tu nous parles, n'est pas le problème des mécaniques CORS. Les mécaniques CORS sont relativement récentes et réfléchies depuis HTML 5 (enfin plus exactement depuis les techniques AJAX), alors que le hacker qui fait ce que tu décris, il existe depuis qu'Internet existe.

Concernant le hacker dont tu parles, c'est pour te protéger de lui que tu demandes un login/mot de passe à tes utilisateurs. Le hacker peut bien essayer ce qu'il veut, sans le login et le mot de passe de quelqu'un d'autre, il ne peut faire que des requêtes qu'on peut faire normalement avec son propre login/mot de passe. Pas un problème donc. S'il veut faire des achats sur ta plate-forme sans passer par ta VueJS, c'est son problème. C'est quand même lui qui les fait, pour lui. C'est un peu exagéré d'appeler ça un hacker.

Alors CORS, c'est pour se protéger de quoi ?

S'il est vrai que le web moderne encourage à créer des APIs pour qu'une vue JavaScript lui fasse des requêtes, il ne faut pas oublier que ces APIs ne sont jamais que des applications web, qui reçoivent des requêtes HTTPS et qui y répondent normalement. Du point de vue d'un ordinateur, une API web n'est qu'un site web normal.

Et qu'est-ce qu'il y a d'autre comme site web normal ? Par exemple un site d'achat en ligne. Le site typique, qui connaît ta carte bleue et qui te propose d'acheter simplement des articles en quelques clics et en indiquant à quelle adresse les livrer. L'utilisateur va sur achats-geniaux.com et le site le connaît bien, grâce aux cookies, et il affiche donc le nom du visiteur et lui propose d'utiliser la carte bleue qu'il connaît pour acheter des trucs. Normal.

Et donc, puisqu'un site web et une API, c'est la même chose, on peut tout à fait utiliser achats-geniaux.com comme une API. Un site web, pas-suspect-du-tout.com, lorsque quelqu'un vient le visiter, peut parfaitement envoyer une requête à achats-geniaux.com comme à une API, demandant à acheter 600 lingots d'or à livrer à monsieur ESCROW, 42 rue de l'arnaque facile.

Puisque achats-geniaux.com connaît le visiteur grâce à ses cookies, et qu'il connaît sa carte bleue, la commande est valide, et monsieur ESCROW vient de se faire livrer 600 lingots d'or payés avec l'argent de quelqu'un qui a visité son site. Simplement parce que cette personne utilise aussi achats-geniaux.com.

Les CORS, ça sert à dire, ouais non.

Les navigateurs n'ont pas envie que leurs utilisateurs soient escroqués en se servant de leurs cookies. Les sites webs n'ont pas envie que leurs clients soient escroqués. Alors les navigateurs et les sites webs ont mis en place un arrangement.

Quand un site web dit à un navigateur de faire un appel d'API, et que cet appel est fait vers un autre domaine, le navigateur se méfie. Il se dit que c'est pas forcément légitime. Il demande d'abord à l'API si elle est d'accord. Pour ça il va faire une première requête OPTION vers la même URL et avec les mêmes headers, et en ajoutant le header "Origin" qui indique quel site web a déclenché la requête.

L'API, voyant ça, va réagir "ah ouais non. Nous n'acceptons de requête que de notre propre origine. Ou par l'un de nos deux autres domaines. Mais personne d'autre" et la requête est rejetée. Et monsieur ESCROW a échoué.

Si par contre la requête est faite par un des domaines autorisés, le navigateur reçoit l'autorisation, et fait la véritable requête en réindiquant tout le reste pareil.

C'est à ça que servent "Access-Control-Allow-Origin" et consorts : indiquer au navigateur quels domaines ont le droit de faire des requêtes à cette API. Et si un site qui n'a pas le droit essaie de le faire quand même, le navigateur lui dit d'aller se faire cuire un œuf chez les grecs ou quelque chose comme ça.

Mais donc, que vérifier ?

Est-ce que tes APIs stockent des cookies/données persistentes sur les navigateurs de leurs visiteurs, pour se rappeler de qui ils sont ?

Si oui, attention, ça veut dire que n'importe quel site web du monde peut envoyer ses visiteurs sur tes APIs pour leur faire faire ce qu'ils veulent, comme acheter 600 lingots d'or et les faire livrer n'importe où.

Dans ce cas, il faudrait pas que tous les sites webs du monde aient le droit de le faire. Il vaudrait mieux limiter ça à ton site web à toi.

Si tes APIs ne savent jamais rien du navigateur qui vient leur dire quelque chose, et qu'elles identifient les utilisateurs à partir d'un access token que VueJS ajoute à la requête à l'API, alors a priori elles ne risquent pas d'attaque de CORS... Mais bon, on sait jamais à quoi un pirate peut penser. Il vaut mieux limiter les accès autant que possible.

[adrienfehr]

Merci beaucoup thelvin bon ta réponse claire et riche.