Cross-Origin-Resource-Sharing (CORS)

Comprendre Cross-Origin Resource Sharing

Par défaut, un navigateur empêche généralement une page web d’accéder librement aux données provenant d’un autre site.

CORS, pour Cross-Origin Resource Sharing, permet à un serveur de préciser quels autres sites sont autorisés à accéder à certaines de ses ressources.

Ce mécanisme est particulièrement important pour les API et les applications web réparties sur plusieurs domaines.

Pourquoi le navigateur bloque-t-il ces accès par défaut ?

Votre navigateur peut être connecté à plusieurs services en même temps : messagerie, banque, administration, réseaux sociaux ou outils professionnels.

Sans séparation entre ces sites, une page malveillante pourrait tenter de récupérer les données d’un autre service déjà ouvert dans le navigateur.

Les navigateurs appliquent donc une règle appelée Same-Origin Policy, qui limite les interactions entre des origines différentes.

CORS permet ensuite d’autoriser certaines exceptions de manière contrôlée.

Configurer CORS

Un exemple simple

Imaginons une application disponible sur :

Cette application doit récupérer des données depuis une API située sur :

Comme les deux adresses appartiennent à des origines différentes, le navigateur ne permet pas automatiquement à l’application d’accéder au contenu de la réponse.

L’API peut alors autoriser explicitement cette origine avec :

Cela indique au navigateur que les pages provenant de https://app.example.com sont autorisées à accéder à la réponse dans ce contexte.

Les principaux en-têtes CORS

Contrairement à CSP ou HSTS, CORS ne repose pas sur un seul en-tête HTTP. Il utilise plusieurs en-têtes complémentaires.

Et l’étoile * ?

Il est possible de rencontrer :

L’étoile signifie que la ressource peut être accessible depuis n’importe quelle origine lorsque cette valeur est applicable.

Pour une ressource entièrement publique, cela peut être volontaire. En revanche, cette configuration ne doit pas être utilisée sans réflexion pour une ressource contenant des données privées ou sensibles.

Éviter les mauvaises configurations

Cookies, sessions et requêtes authentifiées

Certains échanges entre plusieurs sites nécessitent des informations d’identification, par exemple un cookie de session.

CORS prévoit pour cela l’en-tête :

Cette configuration demande une attention particulière. Une origine autorisée peut alors participer à des échanges associés à la session de l’utilisateur.

Les origines autorisées doivent donc être définies précisément lorsque des cookies, des sessions ou d’autres informations d’identification sont impliqués.

Les requêtes preflight

Pour certaines requêtes, le navigateur vérifie d’abord si le serveur autorise réellement l’opération demandée.

Il envoie alors une requête préliminaire, appelée preflight, généralement avec la méthode HTTP :

Le serveur répond en indiquant les origines, méthodes et en-têtes qu’il accepte.

Si les conditions ne sont pas respectées, le navigateur peut empêcher la page d’accéder normalement à la réponse.

Une mauvaise configuration peut exposer des données

Le danger n’est pas simplement d’utiliser CORS. Le problème apparaît lorsqu’un serveur fait confiance à une origine qui ne devrait pas avoir accès à ses données.

Une API contenant des informations privées ne doit par exemple pas autoriser n’importe quel site à consulter ses réponses.

Une politique trop permissive, surtout lorsqu’elle est associée à des requêtes authentifiées, peut contribuer à une exposition ou une fuite de données sensibles.

Bonnes pratiques et limites

Bonnes pratiques

• Autoriser uniquement les origines qui ont réellement besoin d’accéder à la ressource.
• Éviter les politiques trop larges pour les ressources contenant des données privées ou sensibles.
• Être particulièrement prudent lorsque Access-Control-Allow-Credentials est utilisé.
• Limiter les méthodes HTTP aux opérations réellement nécessaires.
• Limiter les en-têtes autorisés à ceux dont l’application a réellement besoin.
• Tester les accès depuis des origines autorisées et non autorisées après toute modification.

CORS n’est pas un mécanisme d’authentification

CORS est principalement appliqué par le navigateur.

Il peut empêcher une page web d’accéder au contenu d’une réponse, mais il ne remplace pas les contrôles de sécurité réalisés directement par le serveur.

Une API doit toujours vérifier elle-même :

• l’identité de l’utilisateur ;
• ses autorisations ;
• les droits associés à l’action demandée ;
• la validité des données reçues.

CORS et CORP ne jouent pas le même rôle

CORS et Cross-Origin-Resource-Policy (CORP) concernent tous les deux les échanges entre plusieurs origines, mais ils ne répondent pas exactement au même besoin.

CORS permet notamment d’autoriser une page à accéder au contenu d’une réponse provenant d’une autre origine.

CORP permet au serveur de définir dans quelles conditions une ressource peut être utilisée dans certains contextes cross-origin.

Ce que CORS ne remplace pas

CORS est une couche de contrôle supplémentaire, mais il ne remplace pas :

• l’authentification ;
• la gestion des droits et des autorisations ;
• HTTPS ;
• la validation des données ;
• la sécurité générale de l’application ou de l’API.

Une politique CORS doit donc être définie précisément en fonction des échanges réellement nécessaires. Une configuration trop permissive peut exposer inutilement des données, tandis qu’une configuration correcte permet de maintenir la séparation entre les différentes applications.