CORS

Qu'est-ce que le CORS ?

Le CORS, pour Cross-Origin Resource Sharing (partage de ressources entre origines multiples), est un mécanisme de sécurité intégré aux navigateurs. Il permet à un serveur de déclarer quelles origines (combinaison d'un protocole, d'un domaine et d'un port) peuvent lire ses réponses depuis du JavaScript exécuté sur une autre origine. Sans lui, un script chargé sur https://app.exemple.com ne pourrait pas lire la réponse d'une requête envoyée à https://api.exemple.com.

Le CORS existe à cause de la politique de même origine (same-origin policy), qui bloque par défaut les lectures entre origines pour protéger les utilisateurs de pages malveillantes. Le CORS est la façon contrôlée d'assouplir cette règle. Il est appliqué par le navigateur, pas par le serveur : des outils comme curl ou Postman l'ignorent.

Comment fonctionne le CORS

Quand une page appelle une autre origine, le navigateur ajoute un en-tête Origin. Le serveur répond avec des en-têtes qui indiquent si cette origine est acceptée. Si la réponse ne correspond pas, le navigateur bloque la réponse et affiche une erreur CORS dans la console, même si la requête a bien atteint le serveur.

Voici une réponse permissive minimale :

Access-Control-Allow-Origin: https://app.exemple.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

Requêtes simples et preflight

Les requêtes simples (GET ou POST avec des en-têtes basiques) partent directement et le navigateur vérifie la réponse ensuite. Tout le reste, comme un PUT, un DELETE ou une requête avec un en-tête Authorization ou un corps JSON, déclenche un preflight : le navigateur envoie d'abord une requête OPTIONS pour demander l'autorisation. Si le serveur n'y répond pas correctement, la vraie requête n'est jamais envoyée.

• Access-Control-Allow-Origin : l'origine autorisée à lire la réponse.
• Access-Control-Allow-Methods : les méthodes HTTP acceptées.
• Access-Control-Allow-Headers : les en-têtes de requête acceptés.
• Access-Control-Allow-Credentials : l'envoi éventuel de cookies et d'identifiants.
• Access-Control-Max-Age : la durée pendant laquelle le navigateur peut mettre en cache le résultat du preflight.

CORS et notions voisines

Le CORS n'est pas un système d'authentification. Il n'empêche ni un script, ni un serveur, ni un robot d'appeler votre API. Il contrôle uniquement ce qu'un navigateur laisse lire à une page web.

Bonnes pratiques et erreurs courantes

• Listez les origines exactes que vous autorisez plutôt que d'utiliser *, surtout pour les API authentifiées.
• Ne combinez jamais Access-Control-Allow-Origin: * avec des identifiants : les navigateurs le refusent.
• Répondez au preflight OPTIONS avec un statut 2xx et les bons en-têtes, avant toute étape d'authentification.
• Vérifiez que les proxys, CDN et API gateways ne suppriment ni ne dupliquent les en-têtes CORS.
• Ajoutez Vary: Origin quand l'origine autorisée varie selon la requête, pour que les caches se comportent correctement.

L'erreur classique « No 'Access-Control-Allow-Origin' header is present » signifie presque toujours que le serveur (ou une couche intermédiaire) ne renvoie pas l'en-tête pour cette origine ou pour le preflight.

Le CORS chez BeBranded

Entre un front Webflow et un back-end sur mesure, un point d'entrée d'automatisation ou une API tierce, le CORS fait partie des premiers détails d'intégration à régler. Notre équipe le configure dans les applications web que nous réalisons, pour que le front et l'API communiquent en toute sécurité sans ouvrir plus d'accès que nécessaire.