CORS : le Cross-Origin Resource Sharing en quelques mots

Il est en réalité strictement interdit : quiconque appelle un site Web ne doit pas charger d’autres données venant de serveurs externes ! Mais il peut y avoir des exceptions. Si les deux exploitants du site s’entendent sur une coopération, rien ne s’oppose à un accord. Le Cross-Origin Resource Sharing (CORS) régit cette coopération. Comment cela fonctionne-t-il ?

Comment fonctionne le CORS ?

La Same-Origin Policy (SOP) interdit le chargement à 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 JavaScript et CSS peuvent charger du contenu provenant d'autres serveurs - même du contenu nuisible – et ce à l'insu de l'utilisateur. Une telle tentative d'accès s'appelle une Cross-Origin Request. Toutefois, si les deux exploitants du site Web sont au courant de l'échange de données et souhaitent 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 applicable qu’à des clients spécifiques. 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 exactement quels serveurs peuvent charger les données et les rendre disponibles à l'utilisateur. Seule l'intégration de caractères wildcards peut accorder une autorisation générale d'accès à tous les clients. Cependant, ceci n'est utile que pour les serveurs qui offrent des informations qui devraient être accessibles au grand public, les polices Web, par exemple.

Dans le meilleur des cas, l'utilisateur ne remarque rien de l'échange entre les deux serveurs impliqués. Tous les navigateurs actuels supportent 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.

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'information 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écifications de l'hôte ne sont pas identiques.

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éralement pas perçus comme un risque lié à la sécurité. La situation est différente avec PATCH, PUT ou DELETE : ils permettent d'effectuer des interventions nuisibles. Par conséquent, le Cross-Origin Resource Sharing doit également être activé à cette fin. Cela signifie que CORS peut contenir non seulement des informations sur la source autorisée, mais aussi sur les requêtes HTTP autorisé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éliminaire 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 considé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 différents CORS Header qui traitent chacun d'aspects différents. Les deux principaux en-têtes permettant de déterminer les origines sûres et les méthodes autorisées ont déjà été mentionnés. Mais il en existe d'autres :

  • Access-Control-Allow-Origin : quelle origine est autorisée ?
  • Access-Control-Allow-Credentials : les requêtes sont-elles autorisées même si le Credentials 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 autorisé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éliminaire ?
  • Access-Control-Request-Headers : quel en-tête HTTP est spécifié dans la requête préliminaire ?
  • Access-Control-Request-Method : quelle méthode HTTP est spécifiée dans la requête préliminaire ?
  • 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écifique, vous pouvez également saisir un caractère wildcard sous la forme d'un asté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 maintenant 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éliminaire à 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 correspondants :

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

Si les en-têtes de la réponse ne correspondent pas aux spécifications 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 inconvénients du CORS

En réalité, le CORS sert à contourner un certain réglage de base, à savoir la Same-Origin Policy. La SOP, représente quant à elle un moyen efficace de prévenir les connexions potentiellement dangereuses. 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 provisoire : des exceptions peuvent être créées à l'aide de CORS pour les situations dans lesquelles des Cross-Origin Requests sont explicitement requises. Toutefois, pour des raisons de commodité, il existe un risque que les exploitants de sites Web n'utilisent que des caractères wildcards qui permettraient d’annuler toute protection de la SOP. Il est donc important de n'utiliser CORS que dans certains cas particuliers, et de le configurer de manière aussi restrictive que possible.

Cet article vous a-t-il été utile ?