Il est en réalité stric­te­ment interdit : quiconque appelle un site Web ne doit pas charger d’autres données venant de serveurs externes ! Mais il peut y avoir des ex­cep­tions. Si les deux ex­ploi­tants du site s’entendent sur une coo­pé­ra­tion, rien ne s’oppose à un accord. Le Cross-Origin Resource Sharing (CORS) régit cette coo­pé­ra­tion. Comment cela fonc­tionne-t-il ?

Comment fonc­tionne le CORS ?

La Same-Origin Policy (SOP) interdit le char­ge­ment à partir d'autres serveurs lors d’une visite d'un site Web. Toutes les données doivent provenir de la même source, c'est-à-dire du même serveur. Il s'agit d'une mesure de sécurité, car Ja­vaS­cript et CSS peuvent charger du contenu provenant d'autres serveurs - même du contenu nuisible – et ce à l'insu de l'uti­li­sa­teur. Une telle tentative d'accès s'appelle une Cross-Origin Request. Toutefois, si les deux ex­ploi­tants du site Web sont au courant de l'échange de données et sou­hai­tent exécuter ce procédé, le processus peut être autorisé. Le serveur interrogé - c'est-à-dire le serveur à partir duquel le contenu doit être chargé - autorise ensuite l'accès via le Cross-Origin Resource Sharing.

Cela n’est cependant ap­pli­cable qu’à des clients spé­ci­fiques. En d’autres mots, le CORS n'est pas une carte blanche pour toutes sortes de Cross-Origin Requests. Au lieu de cela, le second serveur autorise l'accès exclusif au premier serveur via l'en-tête HTTP. L'en-tête de la réponse HTTP décrit exac­te­ment quels serveurs peuvent charger les données et les rendre dis­po­nibles à l'uti­li­sa­teur. Seule l'in­té­gra­tion de ca­rac­tères wildcards peut accorder une au­to­ri­sa­tion générale d'accès à tous les clients. Cependant, ceci n'est utile que pour les serveurs qui offrent des in­for­ma­tions qui devraient être ac­ces­sibles au grand public, les polices Web, par exemple.

Dans le meilleur des cas, l'uti­li­sa­teur ne remarque rien de l'échange entre les deux serveurs impliqués. Tous les na­vi­ga­teurs actuels sup­por­tent le CORS, et l'envoi des requêtes et des réponses à un site Web se fait en arrière-plan sur un laps de temps très court.

Image: Séquence de CORS
CORS contrôle l'accès au contenu des serveurs externes.

Structure du CORS Header

Dans le sens de la Same-Origin Policy, l'in­for­ma­tion sur l'origine d'une connexion de serveur se compose de trois éléments : hôte, port et protocole. Dans l'exemple 'https://example.com' ci-dessus, la politique interdit donc l'accès à 'http://example.com' ou 'https://example.org'. Dans le premier cas, le protocole n'est pas le même ; dans le second, les deux spé­ci­fi­ca­tions de l'hôte ne sont pas iden­tiques.

En principe, une Cross-Origin Request est une requête HTTP. Certaines méthodes ne posent en principe aucun problème. GET et HEAD ne peuvent pas modifier les données et ne sont donc gé­né­ra­le­ment pas perçus comme un risque lié à la sécurité. La situation est dif­fé­rente avec PATCH, PUT ou DELETE : ils per­met­tent d'ef­fec­tuer des in­ter­ven­tions nuisibles. Par con­sé­quent, le Cross-Origin Resource Sharing doit également être activé à cette fin. Cela signifie que CORS peut contenir non seulement des in­for­ma­tions sur la source autorisée, mais aussi sur les requêtes HTTP au­to­ri­sées par la source.

S'il s'agit de méthodes HTTP relatives à la sécurité, le client envoie d'abord une requête pré­li­mi­naire dans laquelle il précise seulement la méthode HTTP qui sera ensuite adressée au serveur. Puis il demande si la requête est con­si­dé­rée comme sûre. Pour cela, il faut utiliser l'en-tête OPTIONS. Ce n'est qu'après une réponse positive que la demande effective peut être effectuée.

Il existe dif­fé­rents CORS Header qui traitent chacun d'aspects dif­fé­rents. Les deux prin­ci­paux en-têtes per­met­tant de dé­ter­mi­ner les origines sûres et les méthodes au­to­ri­sées ont déjà été men­tion­nés. Mais il en existe d'autres :

  • Access-Control-Allow-Origin : quelle origine est autorisée ?
  • Access-Control-Allow-Cre­den­tials : les requêtes sont-elles au­to­ri­sées même si le Cre­den­tials Mode est réglé en include ?
  • Access-Control-Allow-Headers : quels en-têtes peuvent être utilisés ?
  • Access-Control-Allow-Methods : quelles méthodes de requête HTTP sont au­to­ri­sées ?
  • Access-Control-Expose-Headers : quels en-têtes peuvent être affichés ?
  • Access-Control-Max-Age : quel est le délai de validité de la requête pré­li­mi­naire ?
  • Access-Control-Request-Headers : quel en-tête HTTP est spécifié dans la requête pré­li­mi­naire ?
  • Access-Control-Request-Method : quelle méthode HTTP est spécifiée dans la requête pré­li­mi­naire ?
  • Origin : quelle est la source de la requête ?

L'accent est mis sur le premier en-tête. Là, le serveur spécifie quel autre hôte peut y accéder. Outre une adresse spé­ci­fique, vous pouvez également saisir un caractère wildcard sous la forme d'un as­té­risque. Ainsi, le serveur autorise des Cross-Origin Requests provenant de n'importe quelle source.

Exemple de Cross-Origin Resource Sharing

Dans notre exemple ci-dessous, nous supposons main­te­nant que l'hôte A (example.com) souhaite envoyer une requête DELETE à l'hôte B (exemple.org). Le serveur d'origine envoie d'abord une requête pré­li­mi­naire à cet effet :

/OPTIONS
Origin: http://example.com
Access-Control-Request-Method: DELETE

Si l'hôte B n'a aucun problème avec cette Cross-Origin Request, il répondra avec les CORS-Header cor­res­pon­dants :

Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Methods: PUT, POST, DELETE

Si les en-têtes de la réponse ne cor­res­pon­dent pas aux spé­ci­fi­ca­tions de la requête ou si le serveur demandé ne répond pas, aucune Cross-Origin Request ne peut être exécutée.

Avantages et in­con­vé­nients du CORS

En réalité, le CORS sert à con­tour­ner un certain réglage de base, à savoir la Same-Origin Policy. La SOP, re­pré­sente quant à elle un moyen efficace de prévenir les con­nexions po­ten­tiel­le­ment dan­ge­reuses. Cependant, Internet est souvent basé sur de telles Cross-Origin Requests, en raison du grand nombre de demandes de connexion d’un hôte à un autre.

CORS offre donc une solution pro­vi­soire : des ex­cep­tions peuvent être créées à l'aide de CORS pour les si­tua­tions dans les­quelles des Cross-Origin Requests sont ex­pli­ci­te­ment requises. Toutefois, pour des raisons de commodité, il existe un risque que les ex­ploi­tants de sites Web n'uti­li­sent que des ca­rac­tères wildcards qui per­met­traient d’annuler toute pro­tec­tion de la SOP. Il est donc important de n'utiliser CORS que dans certains cas par­ti­cu­liers, et de le con­fi­gu­rer de manière aussi res­tric­tive que possible.

Aller au menu principal