Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage.
Je m'appelle Nicolas Vendor Bernard et aujourd'hui, on va parler d'un sujet que beaucoup de
gens détestent à première vue et ce sujet, ce sont les Cores.
Alors Cores, c'est un acronyme pour Cross Origin Resource Sharing.
C'est en fait une fonctionnalité de sécurité dans les navigateurs web qui permet ou pas
au page web d'accéder aux ressources d'une origine différente de la leur.
Alors quand on parle d'origine, on parle en général du nombre d'omènes, grosso modo.
C'est un concept qui a été introduit en 2005 par un groupe de travail du W3C et il a été standardisé
et implémenté par les navigateurs en 2009. Alors comment est-ce que ça fonctionne globalement ?
En fait, c'est un mécanisme qui se passe entre le client et le serveur grâce aux entêtes,
pardon, HTTP. Le client va demander au serveur s'il peut accéder aux ressources et le serveur
devra répondre oui ou non. Alors c'est plus complexe que ça, mais globalement, le concept,
c'est ça. Ce mécanisme, il va se déclencher uniquement quand le client et le serveur sont
sur deux origines, donc deux domaines différents. C'est une politique qui est assez cruciale parce
qu'elle permet à un serveur d'autoriser très simplement l'accès à un ou plusieurs domaines
spécifiques et même de filtrer des méthodes HTTP précises. Par exemple, une application web qui a
besoin de récupérer des données d'une API terse, elle peut le faire que si le serveur API permet
explicitement les requêtes provenant justement de l'origine de l'application. Et tout ça,
en fait, sans avoir à développer de codes spécifiques parce que tout est prévu dans les
navigateurs modernes. Alors évidemment, il faut un petit peu de codes cotés serveurs,
mais très souvent, on a des packages qui ont été prévues pour ça. Donc pour pouvoir justement
mettre en pratique ces règles Cores, il faut simplement configurer le serveur pour répondre
avec trois entêtes qui sont prévues pour ça. On a la première qui s'appelle access control
allo origin qui va spécifier quels sont les origines qui sont autorisées à accéder à la
ressource. On a access control allo méthodes qui là va lister les méthodes HTTP qui sont autorisées.
Et enfin, access control allo headers qui indiquent quels sont les entêtes de la requête HTTP qui vont
pouvoir être accédées. Alors je vous prends un petit exemple très simple pour que tout le monde
comprenne. Depuis mon navigateur, j'envoie une requête post vers un endpoint qui est appelé par
exemple slash login sur mon serveur. D'abord, le serveur va vérifier si l'origine de la requête,
quand on parle de l'origine de la requête, c'est la valeur qui est stockée dans le
header origin de la requête HTTP correspond à une des origines autorisées par la configuration
Cores. Ici, par exemple, on va dire que notre serveur et notre client sont sur le même nom de
domaine donc pas de soucis. Ensuite, il va vérifier si la méthode post est autorisée dans sa configuration.
Pareil, on va dire que oui. Et enfin, est-ce que les entêtes de la requête sont toutes autorisées ? Et
là, par exemple, on peut imaginer qu'il y a une entête personnalisée qui s'appelle xtereuser qui
n'a rien à faire là. Et du coup, la requête est la rejetée avec une erreur qui va indiquer par
exemple, il y a un token, donc un mot, un valide qui s'appelle xtereuser et qui n'est pas accepté
dans la configuration Cores. Alors je vous mettrai dans les notes de l'épisode, en lien vers une
documentation de chez Modzilla qui liste toutes les erreurs possibles de Cores. En général,
elles sont assez claires, mais en fait, quand on ne comprend pas bien le concept de Cores,
c'est pas toujours évident de les lire. Vous verrez qu'à la fin de l'épisode,
vous aurez compris globalement tout ce qu'il y a à sa bras. Alors le problème, c'est que,
parfois, surtout quand on débute, Cores, ça peut nous rendre un petit peu fou. Parce que là,
on se dit, les Cores, c'est trop bien, ça permet de sécuriser un peu l'accès à mon serveur.
Sauf qu'on a tous et tous eu des erreurs Cores qui arrivaient pour une raison assez obscure. Et
en fait, il y a plusieurs raisons à ça. Mais pour les comprendre, il va falloir qu'on rentre un
petit peu plus loin dans la technique, mais on va y aller progressivement. D'abord, la première
erreur qu'on commet très souvent, surtout quand on débute, c'est qu'on pense être sur la même
origine alors que c'est pas le cas. Parce que si on est sur la même origine, la confiance règne et
les règles Cores ne se déclenche pas. Il faut savoir que les ports réseaux sont pris en compte
dans la comparaison de l'origine. Ça signifie grosso modo que les origines, par exemple,
localhost 2.3, et localhost 2.80, qui par exemple, ça va être votre appli et votre serveur d'API,
ces deux origines-là sont considérées comme étant différentes. Et du coup, les règles Cores se
déclenche. Et potentiellement, si jamais vous n'avez pas configuré votre serveur de dev pour
accepter et pour gérer ce cas-là, et bien vos requêtes vont être rejetées. Même si le projet
est juste en cours de développement et qu'il est déployé, n'y le pas. Mais c'est aussi le cas
des sous-domains. Par exemple, example.com et epi.example.com, ce sont des origines différentes.
Et on peut même aller plus loin puisqu'en fait, le protocole, il est aussi pris en compte.
Alors le protocole, on va plutôt parler en général le schéma quand on parle d'un numérique. Votre
schéma, c'est HTTP ou HTTPS, eh bien, chaque schéma va être considéré comme étant différent.
Par exemple, HTTP.example.com et HTTP.example.com sont différents. Donc il faut bien se rappeler
que l'origine, c'est la combinaison du protocole ou du schéma, du nom de l'autre, ici c'est
example.com et du port, si jamais il y en a un qui est spécifié. Et maintenant, on va passer à la
partie, en fait, dont très peu de gens comprennent réellement le fonctionnement. Jusqu'à aujourd'hui,
si vous écoutez cet épisode, ce sont les requêtes pre-flight. En fait, les requêtes
pre-flight, c'est une implementation technique des règles Cores dans le navigateur. Et en fait,
pour bien comprendre le fonctionnement de ça et l'intérêt de ces requêtes pre-flight, il faut
revenir à l'origine de la création des Cores. Donc on fait ensemble un petit bout dans le passé
jusqu'à l'introduction des Cores dans le navigateur, je vous l'ai dit, c'était en 2009. En fait,
comme la fonctionnalité vient d'arriver et tout juste en d'arriser, la majorité des serveurs web
y possède aucune règle Cores configurée. Donc globalement, ils laissent tout passer,
parce qu'il est normal. Sauf que c'est embêtant, mais en réalité, à l'époque, beaucoup de formuleurs
envoient des données à un autre domaine via, comme j'ai dit, un formulaire HTML. Et donc,
c'est pas possible de bloquer par défaut toutes les requêtes Cros Origin. Sinon,
on casserait tout simplement beaucoup de sites Internet et leurs fonctionnements. Sauf que pour
certaines méthodes HTTP, notamment Putz et Delete, c'est beaucoup plus embêtant parce que ce sont
des requêtes qui impliquent des modifications sur les données du serveur. Là, on parle pas de
récupérer des données ou d'ajouter des données, on parle carrément de modifier ou d'en supprimer.
Donc ça fait de ces requêtes-là des requêtes beaucoup plus sensibles que les autres, surtout
quand elles viennent d'une origine différente. Et en fait, c'est là que l'implémentation des
cornes dans l'invigateur a été faite de manière très astuciuse, parce qu'on va avoir deux mécanismes
différents en fonction des requêtes. Pour les requêtes considérées comme simples, je me déguimais
que vous ne voyez pas, mais c'est des requêtes simples. Donc les requêtes GET et POST et qui
contiennent uniquement des entêtes standard, on va laisser le serveur appliquer ces règles cornes.
On va lui-même le laisser les gérer. S'il n'y a aucune règle corne, il traitera simplement
la requête, même s'il y a bien d'une origine différente. Mais dans le cas d'une requête complexe,
comme PUT, DELETE ou une requête même GET ou POST mais qui a des entêtes personnalisées ou qui
sont pas standardisées, le navigateur, ce qu'il va faire, c'est qu'il va envoyer deux requêtes.
Il va d'abord envoyer une requête PRIFLYTE et ensuite, il va envoyer la vraie requête.
Préflyte, on peut appeler ça une requête préalable. Donc la requête PRIFLYTE,
c'est une requête OPTIONS, c'est la méthode qui est en général utilisée. Elle va être envoyée par
le navigateur pour vérifier la politique COREZ du serveur. Grosso modo, la requête OPTIONS,
elle va demander au serveur, tiens, toi, c'est quoi ta configuration COREZ, ce sont quoi tes
entêtes COREZ ? Et donc le serveur, il y a deux solutions. Soit le serveur répond donc ces entêtes
COREZ et là, le navigateur se rend compte que les entêtes COREZ correspondent et valide la requête
qu'il doit envoyer, la vraie requête qu'il doit envoyer. Dans ce cas-là, tout va bien,
le navigateur, il poursuit avec la requête réelle. Mais si le serveur, il répond avec des entêtes,
soit qu'il ne correspond pas à la future requête, ou tout simplement s'il ne répond pas à cette
requête OPTION, eh bien la vraie requête ne sera jamais envoyée. En fait, c'est un mécanisme qui
permet au navigateur de forcer le serveur à déclarer sa politique COREZ pour laisser passer
les requêtes complexes pour que le navigateur accepte de les envoyer. Alors là, quand je vous
l'explique comme ça, ça paraît logique, mais très honnêtement, j'ai passé plusieurs heures à
enseigner sur le sujet parce que la plupart des explications sur internet sont vraiment trop vagues
ou tout simplement à côté de la plaque. Alors avant de finir cet épisode, je voulais simplement
revenir sur quelque chose et que vous devez savoir, vous devez tout simplement comprendre que les règles
COREZ, ce n'est pas une défense infaillible contre les requêtes qui viennent d'autres origines,
très loin de la main. En fait, comme on l'a dit, la vérification de l'origine,
elle se fait grâce à l'entête origine dans la requête HTTP. Et effectivement,
cette entête, elle contient en général le nom d'hommène, le protocole, le port utilisé
par le site qui est envoyé la requête. Sauf qu'en réalité, c'est le navigateur ou plus
généralement le client HTTP qui décide de cette entête. Donc dans un navigateur classique,
l'entête et contiendra la bonne info. Mais si la requête, elle est envoyée depuis un autre
client HTTP, un autre serveur, peu importe, l'origine, elle pourra être modifiée ou en
tout cas, elle pourra être mise avec une valeur qui est complètement à la décision du développeur
ou de la développeuse. On peut parler parfois de spoofing d'origine, même si ce n'est pas réellement
du spoofing puisque c'est déjà quelque chose qui est plus ou moins un champ libre. Mais du
coup, il faut bien garder en tête que les règles COREZ sont effectivement là pour réguler un petit
peu le trafic classique du web tout simplement. Mais ça ne va pas sécuriser vos données au-delà
de ça. On pourra quand même faire des requêtes à votre serveur qui passeront malgré vos règles
COREZ. C'est simplement un mécanisme des navigateurs web, mais ça s'arrête là en
termes de protection et de sécurité. J'espère que cet épisode vous aura plu et que vous en
aurez appris un peu plus, voire complètement plus sur les COREZ. Moi, je vous donne rendez-vous la
semaine prochaine pour un prochain épisode du podcast et comme d'habitude, passez sur code
tirégarage.fr pour retrouver tous les articles du blog, tous les épisodes de podcast et évidemment
tous nos cours complets pour apprendre tout ce que vous avez à savoir, notamment si vous recherchez un
emploi ou si vous voulez devenir freelance, on a des cours que vous trouverez nuls par ailleurs qui
sont super bien notés et avec des vrais avis positifs. Donc, venez faire un tour et c'est
sûr que vous trouverez votre bonheur. Je vous donne rendez-vous la semaine prochaine pour un prochain
épisode du podcast. Salut !