Cross-origin resource sharing

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

Le partage de ressource de différentes origines (cross-origin resource sharing, CORS) est un mécanisme qui permet à des ressources limitées (par exemple, les polices de caractères) sur une page web, d'être chargée à partir d'un domaine hors de celui à partir duquel la première ressource a été servi. Une page web peut librement intégrer des ressources d'une origine différentes comme des images, des feuilles de style, des scripts, des iframes et des vidéos[1]. Certaines demandes "inter-domaine" (en anglais : cross-domain), notamment l'ajax, sont interdites par défaut par la politique de sécurité de même origine (en anglais : same origin security policy).

CORS définit un cadre dans lequel un navigateur et le serveur peuvent interagir afin de déterminer si oui ou non il est sûr de permettre une demande cross-origin[2]. Il permet plus de liberté et de fonctionnalités que les requêtes purement de même d'origine, mais est plus sûr que de simplement autoriser toutes les requêtes cross-origin. C'est un standard recommandé par la norme du W3C[3].

Comment fonctionne CORS[modifier | modifier le code]

Le standard CORS décrit de nouvelles entête HTTP qui offre aux navigateurs et aux serveurs un moyen de faire une requête vers une url distante uniquement s'ils en ont l'autorisation. Bien que certaines validations et autorisations peuvent être effectuées par le serveur, il est généralement de la responsabilité du navigateur de supporter ces en-têtes et d'honorer les restrictions qu'elles imposent.

Pour l'ajax et les méthodes de demande HTTP qui peuvent modifier des données (généralement des méthodes HTTP autres que GET, ou pour POST avec l'utilisation de certains types MIME), la spécification mandate que les navigateurs "contrôlent en amont" la demande, en sollicitant le test des méthodes prises en charge par le serveur via une requête HTTP OPTIONS, puis, lors de "l'approbation" du serveur, l'envoi de la demande réelle avec la méthode de requête HTTP. Les serveurs peuvent également informer les clients si les "informations d'identification" (y compris les Cookies et les données d'Authentification HTTP) doivent être envoyés avec la demande[4].

Flowchart showing Simple and Preflight XHR.svg

Exemple Simple[modifier | modifier le code]

Ce n'est généralement pas appropriée lors de l'utilisation de la politique de sécurité de même origine. Lorsqu'un navigateur CORS-compatible tente de faire une requête cross-origin :

  1. Le navigateur envoie la requête OPTIONS avec une Origin en-tête HTTP. La valeur de cet en-tête est le domaine qui a servi la page parente. Lorsqu'une page de http://www.example.com tente d'accéder aux données d'un utilisateur de http://service.example.com les en-têtes de requêtes suivantes seront envoyées à http://service.example.com :
  2. Le serveur de http://service.example.com peut répondre avec :
    • Une entête Access-Control-Allow-Origin (ACAO) dans sa réponse en indiquant quels sites d'origine sont autorisées. Par exemple :
    • Une page d'erreur si le serveur n'autorise pas la requête cross-origin.
    • Une entête Access-Control-Allow-Origin (ACAO) avec comme valeur une étoile qui autorisera tous les domaines :

Une politique de même origine définie par une étoile est appropriée lorsqu'une page ou le contenu d'une réponse de l'API est considérée comme totalement public et qu'il est destiné à être accessible à tout le monde, y compris par n'importe quel code sur n'importe quel site. Par exemple, une polices web gratuite sur un service d'hébergement comme Google Fonts.

Une politique de même origine définie par une étoile est également largement utilisé et de manière appropriée pour des objet-modèle de capacité, où les pages ont des url non-déterministe et qui sont destinés à être accessible uniquement aux personnes connaissant le secret.

La valeur "*" est spécial en ce sens qu'il ne permet pas aux demandes de fournir des informations d'identification comme de l'authentification HTTP, des certificats SSL client, ni d'envoyer des cookies[5].

Notez que dans les architectures CORS, l'entête ACAO est fixée par le service web externe (service.example.com), et non par le serveur d'applications web (www.example.com). CORS permet au service web externe d'autoriser l'application web à utiliser son api et n'a pas de contrôle sur les services externes accédés par l'application web. Pour ce dernier cas, la Politique de Sécurité de Contenu doit être utilisés (la directive connectez-src).

Exemple de contrôle en amont[modifier | modifier le code]

Lors de l'exécution de certains types de requêtes ajax inter-domaine, les navigateurs qui prennent en charge CORS vont insérer une requête supplémentaire de "contrôle en amont" afin de déterminer s'ils ont l'autorisation d'effectuer l'action.

Si service.example.com est disposé à accepter l'action, il peut réagir avec les en-têtes suivants:

Les en-têtes[modifier | modifier le code]

Les en-têtes HTTP qui se rapportent à CORS sont :

En-têtes de requête[modifier | modifier le code]

  • Origin
  • Access-Control-Request-Method
  • Access-Control-Request-Headers

En-têtes de réponse[modifier | modifier le code]

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Credentials
  • Access-Control-Expose-Headers
  • Access-Control-Max-Age
  • Access-Control-Allow-Methods
  • Access-Control-Allow-Headers

Support des navigateurs[modifier | modifier le code]

CORS est supporté par tous les navigateurs basés sur les moteurs de rendu suivant :

  • Navigateurs basé sur Blink- et Chromium (Chrome 28+[6],[7], Opera 15+, Amazon Silk, Android's 4.4+ WebView et de Qt's WebEngine)
  • Gecko 1.9.1 (Firefox 3.5[8], SeaMonkey 2.0[9], Camino 2.1[10]) et plus récent.
  • MSHTML/Trident 6.0 (Internet Explorer 10) a un support natif.[11] MSHTML/Trident 4.0 Et 5.0 (Internet Explorer 8 & 9) fourni un support partiel via l'objet XDomainRequest.
  • Les navigateurs basés sur Presto (Opéra) implémentent CORS à partir de Opera 12.00[12] et Opera Mobile 12, mais pas Opera Mini[13].
  • WebKit (révision Initiale incertaine, Safari 4 et supérieur[14], Google Chrome 3 et supérieur, voir peut-être plus tôt)[15].

À noter également le manque de support de CORS pour les navigateurs suivants :

  • Camino n'implémente pas CORS dans sa série de Release 2.0.x release series, car ces versions sont basés sur Gecko 1.9.0[16].
  • À partir de la version 0.10.2, Arora expose l'API CORS liées à WebKit, mais les tentatives de requêtes cross-origin échouent[17].

Histoire[modifier | modifier le code]

Le support de cross-origin a été proposé initialement par Matt Oshry, Brad Porter, et Michael Bodell de Tellme Networks en mars 2004 pour son inclusion dans VoiceXML 2.1[18] , afin de permettre la des requêtes cross-origin sûre par le navigateurs VoiceXML. Le mécanisme a été jugée de nature générale et non spécifique à la VoiceXML et a par la suite été séparés dans une NOTE d'implémentation[19]. Le groupe de travail WebApps du W3C, avec la participation des principaux éditeurs de navigateurs ont commencé à officialiser la NOTE dans une ébauche de Projet W3C dirigé vers une Recommandation formelle du W3C.

En mai 2006, la première ébauche du projet W3C a été soumise[20]. En mars 2009, le projet a été renommé en "Cross-Origin Resource sharing"[21] et, en janvier 2014, il a été accepté comme une Recommandation du W3C.[22]

CORS vs JSONP[modifier | modifier le code]

CORS peut être utilisé comme une alternative moderne au modèle JSONP. JSONP ne supporte que la méthode GET, CORS quant à lui prend également en charge d'autres types de requêtes HTTP. CORS permet au programmeur web d'utiliser l'habituel XMLHttpRequest, qui à une meilleure gestion des erreurs que JSONP. D'autre part, JSONP fonctionne sur les navigateurs anciens qui datent d'avant le support de CORS. CORS est pris en charge par la plupart des navigateurs web modernes. Aussi, alors que JSONP peut causer des trous de sécurité via cross-site scripting (XSS) lorsque le site est compromis, CORS permet aux sites web de traiter manuellement les réponses pour assurer la sécurité[23].

Voir aussi[modifier | modifier le code]

Références[modifier | modifier le code]

  1. « Same-origin policy / Cross-origin network access », MDN
  2. « Cross-domain Ajax with Cross-Origin Resource Sharing », NCZOnline (consulté le 5 juillet 2012)
  3. « Cross-Origin Resource Sharing »
  4. « cross-site xmlhttprequest with CORS »(ArchiveWikiwixArchive.isGoogleQue faire ?), MOZILLA (consulté le 5 septembre 2012)
  5. Cross-Origin Resource Sharing.
  6. « Blink », QuirksBlog, (consulté le 4 avril 2013)
  7. (en) « Google going its own way, forking WebKit rendering engine », Ars Technica,‎ (lire en ligne)
  8. « HTTP access control (CORS) - MDN », Developer.mozilla.org (consulté le 5 juillet 2012)
  9. « Gecko - MDN », Developer.mozilla.org, (consulté le 5 juillet 2012)
  10. « What makes Camino Special » (consulté le 20 février 2013)
  11. Tony Ross et Program Manager, « CORS for XHR in IE10 », MSDN, (consulté le 14 décembre 2012)
  12. David Honneffer, Documentation Specialist, « 12.00 for UNIX Changelog », Opera, (consulté le 5 juillet 2012)
  13. David Honneffer, Documentation Specialist, « Opera Software: Web specifications support in Opera Presto 2.10 », Opera.com, (consulté le 5 juillet 2012)
  14. on July 6, 2009 by Arun Ranganathan, « cross-site xmlhttprequest with CORS ✩ Mozilla Hacks – the Web developer blog »(ArchiveWikiwixArchive.isGoogleQue faire ?), Hacks.mozilla.org, (consulté le 5 juillet 2012)
  15. « 59940: Apple Safari WebKit Cross-Origin Resource Sharing Bypass », Osvdb.org (consulté le 5 juillet 2012)
  16. « HTTP Access Control in Camino • mozillaZine Forums », Forums-test.mozillazine.org (consulté le 5 juillet 2012)
  17. « Issue 904 - arora - Arora providing API for CORS (Cross-Origin Resource Sharing) but fails in actual use - Cross Platform WebKit Browser - Google Project Hosting », Code.google.com, (consulté le 5 juillet 2012)
  18. « Voice Extensible Markup Language (VoiceXML) 2.1 », W3.org, (consulté le 5 juillet 2012)
  19. « Authorizing Read Access to XML Content Using the <?access-control?> Processing Instruction 1.0 », W3.org (consulté le 5 juillet 2012)
  20. « Authorizing Read Access to XML Content Using the <?access-control?> Processing Instruction 1.0 W3C - Working Draft 17 May 2006 », W3.org (consulté le 17 août 2015)
  21. « Cross-Origin Resource Sharing - W3C Working Draft 17 March 2009 », W3.org (consulté le 17 août 2015)
  22. « Cross-Origin Resource Sharing - W3C Recommendation 16 January 2014 », W3.org (consulté le 17 août 2015)
  23. « When can I use... Cross Origin Resource Sharing », caniuse.com (consulté le 12 juillet 2012)

Liens externes[modifier | modifier le code]