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 ?

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.

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 :

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

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.

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.