Qu'est-ce que le CORS ?

Auparavant, lorsque les technologies Internet étaient encore nouvelles, des problèmes de falsification de requêtes intersites (CSRF, cross-site request forgery) se produisaient. Ces problèmes consistaient en l'envoi de fausses requêtes client depuis le navigateur de la victime vers une autre application.

Par exemple, la victime se connectait à l'application de sa banque. Elle était ensuite incitée à charger un site Web externe sur un nouvel onglet du navigateur. Le site Web externe utilisait ensuite les informations d'identification de cookie de la victime et transmettait des données à l'application bancaire tout en se faisant passer pour la victime. Des utilisateurs non autorisés profitaient alors d'un accès involontaire à l'application bancaire.

Pour éviter de tels problèmes CSRF, tous les navigateurs mettent désormais en œuvre la politique de même origine.

Politique de même origine

Aujourd'hui, les navigateurs imposent aux clients d'envoyer des requêtes uniquement à une ressource ayant la même origine que leur URL. Le protocole, le port et le nom d'hôte de l'URL du client doivent tous correspondre au serveur qui reçoit la requête.

Par exemple, comparez les origines des URL suivantes et de l'URL du client http://store.aws.com/dir/page.html.

URL	Résultat	Raison
http://store.aws.com/dir2/new.html	Même origine	Seul le chemin diffère
http://store.aws.com/dir/inner/other.html	Même origine	Seul le chemin diffère
https://store.aws.com/page.html	Origine différente	Protocole différent
http://store.aws.com:81/dir/page.html	Origine différente	Port différent (http:// est le port 80 par défaut)
http://news.aws.com/dir/page.html	Origine différente	Hôte différent

La politique de même origine est donc hautement sécurisée, mais rigide pour les cas d'utilisation authentiques.

Le partage des ressources entre origines multiples (CORS, cross-origin resource sharing) est une extension de la politique de même origine. Vous en avez besoin pour partager des ressources autorisées avec des tiers externes. Par exemple, vous avez besoin du CORS lorsque vous souhaitez extraire des données à partir d'API externes publiques ou autorisées. Vous en avez également besoin si vous souhaitez permettre à des tiers autorisés d'accéder aux ressources de votre propre serveur.

En HTTP, les méthodes de requête sont les opérations de données que le client souhaite que le serveur effectue. Les méthodes HTTP courantes incluent GET, POST, PUT et DELETE.

Dans le cadre d'une interaction de partage des ressources entre origines multiples (CORS) normale, le navigateur envoie les en-têtes de requête et de contrôle d'accès en même temps. Il s'agit généralement de requêtes de données GET considérées comme présentant peu de risques.

Toutefois, certaines requêtes HTTP sont considérées comme complexes et nécessitent une confirmation du serveur avant leur envoi réel. Le processus d'approbation préalable est appelé requête de pré-vérification.

Requêtes multi-origines complexes

Les requêtes multi-origines sont complexes si elles utilisent l'un des éléments suivants :

• Méthodes autres que GET, POST ou HEAD
• En-têtes autres que Accept-Language, Accept ou Content-Language
• En-têtes Content-Type autres que multipart/form-data, application/x-www-form-urlencoded ou text/plain

Ainsi, par exemple, les requêtes de suppression ou de modification de données existantes sont considérées comme complexes.

Comment fonctionnent les requêtes de pré-vérification

Les navigateurs créent des requêtes de pré-vérification si elles sont nécessaires. Il s'agit d'une requête OPTIONS comme la suivante.

OPTIONS /data HTTP/1.1 Origine : https://example.com Access-Control-Request-Method : DELETE

Le navigateur envoie la demande de pré-vérification avant le vrai message de requête. Le serveur doit répondre à la demande de pré-vérification en fournissant des informations sur les requêtes multi-origines qu'il est prêt à accepter à partir de l'URL du client. Les en-têtes de réponse du serveur doivent inclure les éléments suivants :

• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin

Un exemple de réponse du serveur est donné ci-dessous.

HTTP/1.1 200 OK Access-Control-Allow-Headers : Content-Type Access-Control-Allow-Origin : https://news.example.com Access-Control-Allow-Methods : GET, DELETE, HEAD, OPTIONS

La réponse de pré-vérification inclut parfois un en-tête Access-Control-Max-Age supplémentaire. Cette métrique indique la durée (en secondes) pendant laquelle le navigateur met en cache les résultats de pré-vérification dans le navigateur. La mise en cache permet au navigateur d'envoyer plusieurs requêtes complexes entre les requêtes de pré-vérification. Il n'est pas nécessaire d'envoyer une autre requête de pré-vérification avant l'expiration du délai spécifié par max-age.

 

Vous devez suivre les recommandations suivantes lorsque vous configurez le partage des ressources entre origines multiples (CORS) sur votre serveur.

Définissez des listes d'accès appropriées

Il est toujours préférable d'accorder l'accès à des domaines individuels à l'aide de listes séparées par des virgules. Évitez d'utiliser des caractères génériques, sauf si vous souhaitez rendre l'API publique. Dans le cas contraire, l'utilisation de caractères génériques et d'expressions régulières peut entraîner des vulnérabilités.

Supposons, par exemple, que vous écriviez une expression régulière qui accorde l'accès à tous les sites portant le suffixe permitted-website.com. À l'aide d'une seule expression, vous accordez l'accès à api.permitted-website.com et à news.permitted-website.com. Mais vous accordez également par inadvertance l'accès à des sites non autorisés susceptibles d'utiliser des domaines tels que maliciouspermitted-website.com.

Évitez d'utiliser une origine null dans votre liste

Certains navigateurs envoient la valeur null dans l'en-tête de requête pour certains scénarios tels que les requêtes de fichiers ou les requêtes provenant de l'hôte local.

Toutefois, vous ne devez pas inclure cette valeur dans votre liste d'accès. Cela présente également des risques de sécurité, car des requêtes non autorisées contenant des en-têtes null peuvent obtenir l'accès.