CORS expliqué : importance du partage de ressources entre domaines dans le développement Web

Vous vous demandez ce qu'est CORS (Cross-Origin Resource Sharing)?

Dans les films d'espionnage, les agents de sécurité ont un codé moyen de transmettre des informations entre eux. Comme ils transmettent principalement des informations qui peuvent être utilisées contre eux si elles tombent entre les mains de leurs ennemis, ils doivent s'assurer que ceux qui reçoivent ces informations sont des parties de confiance. Il en va de même pour ceux qui envoient lesdites informations. Lorsque l'expéditeur et le destinataire sont dignes de confiance, la crédibilité et la sécurité des informations peuvent être garanties.

Une réplique de ce scénario se produit dans la communication entre les navigateurs et les serveurs Web et s'appelle la politique de même origine.

What is the Same-Origin Policy?

Avez-vous déjà remarqué que les pages Web ne peuvent pas accéder aux ressources d'un autre site Web ? Cela est dû à la politique d'origine identique, qui est une fonctionnalité de sécurité des navigateurs Web qui empêche les pages Web d'accéder aux ressources (telles que les cookies, les scripts et d'autres données) à partir d'un domaine différent de celui qui a servi la page.

Une origine est définie par la combinaison du protocole, du domaine et du numéro de port d'une URL. La plupart des navigateurs, y compris Chrome, Firefox, Safari et Edge, mettent en œuvre une politique de même origine pour protéger vos données.

Maintenant, pourquoi avons-nous besoin de cette politique ? Pour comprendre cela, regardons comment fonctionne Internet. Vous visitez un site Web, votre navigateur envoie une demande au hébergement de serveur ce site Web, et le serveur répond en renvoyant les ressources nécessaires pour afficher la page. Ces ressources peuvent inclure HTML, CSS, JavaScript et des images. 

Imaginez qu'une page Web puisse également envoyer des requêtes à d'autres domaines. Pour continuer avec notre prémisse de film d'espionnage, un agent secret d'une autre agence veut entrer en contact avec un agent d'une organisation ou d'un pays différent, demander l'accès et partager des informations. Si cette opportunité leur est accordée, cela expose la future organisation à d'énormes vulnérabilités de sécurité. Ils peuvent voler des informations sensibles et potentiellement leur nuire. 

La politique de la même origine est en place pour s'attaquer précisément à ce problème. Bien qu'il y ait quelques malentendus à propos de SOP, cela ne signifie pas que vous ne pouvez pas charger des ressources d'origines différentes ou envoyer des informations à une autre origine. 

Cependant, SOP définit des règles qui limitent l'accès et l'interaction entre différentes ressources, telles que les scripts, CSS, iframes, images et vidéos. C'est comme un garde qui garde les pages Web dans leur propre domaine et les empêche d'accéder aux ressources d'autres domaines. 

Cela vous protège des attaques malveillantes qui pourraient voler vos données ou vous inciter à effectuer des actions indésirables.

What is CORS?

Dans un cas réel, lorsque les agents de sécurité donnent une règle selon laquelle la communication ne doit avoir lieu qu'entre ses agents comme moyen de sécurité, c'est similaire à la politique de la même origine. Pourtant, il peut y avoir des cas où ils devront interagir avec le monde extérieur. Ou avec des agents d'autres services de sécurité, pour que cela se produise, ils peuvent mettre en œuvre une autre mesure de sécurité pour vérifier ces agents. Cette vérification peut se faire de différentes manières, selon les opérateurs impliqués. En cas de communication sur Internet, CORS est le mécanisme qui permet aux navigateurs d'accéder à des ressources qu'ils ne pourront pas à l'origine parce que la ressource est d'une origine différente.

Le partage de ressources inter-origines (CORS) est un mécanisme qui utilise des en-têtes HTTP supplémentaires pour indiquer aux navigateurs de donner à une application Web exécutée à une origine, l'accès à des ressources sélectionnées d'une origine différente.

J'ai parlé de l'origine plus d'une fois, et vous vous demandez probablement ce que cela signifie. Une origine est définie par le protocole, le domaine et le port de l'URL. Lorsque vous avez votre API à une origine telle que https://api.geekflare.com:3001 et votre frontend à https://geekflare.com, les origines sont dites différentes. Dans cette situation, vous aurez besoin de CORS pour pouvoir accéder aux ressources aux deux extrémités.

Lorsque des requêtes sont adressées à un serveur, les navigateurs (client) et les serveurs envoient des requêtes et des réponses, les en-têtes HTTP sont inclus. Parmi ces en-têtes, des en-têtes supplémentaires sont inclus pour empêcher le navigateur de bloquer la communication.

Pourquoi le navigateur bloque-t-il la communication?

Ses fonctionnalités de sécurité du navigateur. Il le fera si la demande provient d'une origine différente de celle du client. Les en-têtes supplémentaires inclus à la suite de CORS sont un moyen d'indiquer au client qu'il peut utiliser la réponse qu'il a reçue.

Common Issues with CORS

En tant que développeur Web, vous avez besoin d'accéder à des ressources de différents domaines, comme lors de la création d'une application Web qui utilise APIs provenant de plusieurs sources. Vous implémentez CORS, qui permet aux serveurs Web de spécifier quels autres domaines sont autorisés à accéder à leurs ressources, afin que vous puissiez toujours créer les applications Web souhaitées. Ce comportement est implémenté côté serveur, il ne peut donc pas être reconfiguré côté client. 

Si vous rencontrez une erreur CORS, cela signifie que le serveur a refusé votre demande d'accès à ses ressources à partir d'un domaine différent car il ne répond pas aux normes de sécurité requises.

Cela peut se produire si le serveur n'a pas les bons paramètres en place. Mais ne vous inquiétez pas, il existe un moyen simple de le réparer. Assurez-vous simplement de vérifier que l'en-tête Access-Control-Allow-Origin est correctement configuré. Cela indique au serveur quels domaines sont autorisés à accéder à ses ressources, donc s'il n'est pas configuré correctement, vous risquez de rencontrer des problèmes.

Voici quelques autres problèmes que vous pouvez rencontrer : 

• Si vous essayez d'utiliser un méthode HTTP non simple (comme DELETE ou PUT) dans une requête de partage de ressources Cross-Origin, il est important de s'assurer que le serveur l'autorise. Les navigateurs n'autorisant que les méthodes simples par défaut, vous devrez donc définir explicitement l'en-tête Access-Control-Allow-Methods si vous souhaitez utiliser une méthode différente.
• De plus, lorsque vous effectuez de telles demandes, vous devez faire attention à l'envoi d'informations d'identification (comme des cookies ou des en-têtes d'autorisation) à partir du navigateur autorisé par le serveur.  
• De plus, le serveur ne répondra pas correctement si l'enquête "preflight" pour une requête non simple (comme celle avec des en-têtes personnalisés) révèle qu'elle n'est pas prise en charge.
• Si une page Web tente d'accéder à des ressources (hébergées sur un Content Delivery Network) telles que des images, des scripts ou des feuilles de style d'un domaine différent, le serveur hébergeant la ressource peut ne pas autoriser les demandes provenant du domaine sur lequel la page est hébergée. 

Heureusement, il existe plusieurs façons de résoudre ce problème. Une solution consiste à configurer le serveur pour autoriser les requêtes cross-origin en envoyant les en-têtes appropriés.

Une autre option consiste à utiliser un serveur proxy pour effectuer la demande au nom de votre application Web ou à utiliser JSON-P pour encapsuler la réponse dans une fonction de rappel.

De plus, il existe des bibliothèques qui simplifient les requêtes cross-origin côté client en gérant les en-têtes et en fournissant une API de requête sans problème.

En essayant ces différentes solutions, vous pouvez contourner ces problèmes et vous assurer que votre application Web peut accéder aux ressources dont elle a besoin pour fonctionner correctement.

Un mot de prudence – ces techniques peuvent avoir leurs propres risques de sécurité, il est donc important de les utiliser avec précaution !

CORS Headers

Un de en-têtes sécurisés qui peut être une réponse ou un en-tête de demande.

En-têtes de réponse

Ce sont les en-têtes que le serveur renvoie dans sa réponse.

• Access-Control-Allow-Origin: <origin>: Ceci est utilisé pour spécifier l'origine autorisée à accéder à la ressource sur le serveur. Il est possible de spécifier que seules les demandes provenant d'une origine spécifique sont autorisées - Access-Control-Allow-Origin: https://geekflare.com, ou que l'origine n'a pas d'importance - Access-Control-Allow-Origin: *.
• Access-Control-Expose-Headers: <headers>: Comme son nom l'indique, cela répertorie les en-têtes auxquels le navigateur a accès.
• Access-Control-Max-Age: <seconds>: Ceci indique la durée pendant laquelle la réponse d'une demande de contrôle en amont peut être mise en cache.
• Access-Control-Allow-Credentials: <boolean>: Cela indique que le navigateur peut utiliser la réponse lorsque la demande initiale a été faite avec un identifiant.
• Access-Control-Allow-Methods: <methods>: Ceci indique la (les) méthode (s) autorisée (s) lors de la tentative d'accès à une ressource.
• Access-Control-Allow-Headers: <headers>: Cela indique que les en-têtes HTTP peuvent être utilisés dans une requête.

Voici un exemple de ce à quoi ressemblera la réponse

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
Vary: Access-Control-Request-Headers
Access-Control-Allow-Headers: Content-Type, Accept
Content-Length: 0
Date: Sat, 16 Nov 2019 11:41:08 GMT+1
Connection: keep-alive

En-têtes de demande

Voici les en-têtes que la requête d'un client doit contenir pour pouvoir utiliser le mécanisme CORS.

• Origin: <origin>: Ceci indique l'origine de la demande du client. Lorsque vous travaillez avec un frontend et un backend, comme indiqué précédemment, ce sera l'hôte de votre application frontend.
• Access-Control-Request-Method: <method>: Ceci est utilisé dans une demande de contrôle en amont pour indiquer la méthode HTTP qui sera utilisée pour effectuer la demande.
• Access-Control-Request-Headers: <header>: Ceci est utilisé dans une demande de contrôle en amont pour indiquer les en-têtes HTTP qui seront utilisés pour effectuer la demande.

Voici un exemple de ce à quoi ressemblera une demande

curl -i -X OPTIONS localhost:3001/api \
-H 'Access-Control-Request-Method: GET' \
-H 'Access-Control-Request-Headers: Content-Type, Accept' \
-H 'Origin: http://localhost:3000'

Preflight Requests

Après avoir mentionné les demandes de contrôle en amont ici et là, qu'est-ce que cela pourrait signifier?

Les demandes de contrôle en amont se produisent lorsque le client doit envoyer une demande de contrôle en amont avant la demande principale. le demande de contrôle en amont est plus un sonde pour déterminer si le serveur prend en charge la requête principale sur le point d'être effectuée. Lorsque la confirmation positive est obtenue, la requête principale est alors envoyée.

Lorsqu'une demande n'est pas une demande de contrôle en amont, elle est appelée demande simple.

Implementing CORS

Vous souhaiterez principalement configurer les éléments au niveau du backend de votre application. L'implémentation dépend du framework que vous utilisez. Pour ce tutoriel, nous verrons comment le faire dans NodeJS et Rails.

Rails

Je vous recommande d'utiliser le rack-cors gemme. Ensuite, vous devrez l'ajouter à votre config/application.rb fichier.

config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'
    resource '*',
       headers: :any,
       expose: %i(access-token expiry token-type uid client),
       methods: %i(get post put patch delete options head),
       credentials: true
  end
end

NodeJS

Dans Node.js, cela ressemblera à ceci.

app.all(‘*’, (req, res, next) => {
  res.header(‘Access-Control-Allow-Origin’, ‘*’);
  res.header(‘Access-Control-Allow-Methods’, ‘PUT, GET, POST, DELETE, PATCH, OPTIONS HEAD’);
  res.header(‘Access-Control-Allow-Headers’, ‘*’);
  res.header(‘Access-Control-Allow-Credentials’, true);
  next();
});

Dans l'extrait de code, nous configurons l'origine, les méthodes, les en-têtes et les informations d'identification qui doivent être autorisés à accéder aux ressources disponibles sur notre serveur. Et pour implémenter dans Apache ou Nginx, reportez-vous à ceci guide.

Conclusion

CORS assouplit la politique afin que votre navigateur puisse accéder aux ressources que vous souhaitez. Comprendre ce que c'est, pourquoi c'est essentiel et comment le configurer vous aidera à déterminer les problèmes que vous pourriez rencontrer lors de la création de vos applications Web.