Testeur CORS

Postman et curl ne sont pas des navigateurs, donc ils ignorent complètement la politique de même origine — ils envoient la requête et lisent la réponse quels que soient les en-têtes reçus. Un navigateur est plus strict : lorsque du JavaScript sur une origine appelle un schéma, un domaine ou un port différent, il ne laisse votre code lire la réponse que si le serveur renvoie le bon en-tête Access-Control-Allow-Origin. Si cet en-tête est absent, la requête atteint quand même le serveur et renvoie des données, mais le navigateur masque la réponse à votre script et consigne l'erreur CORS dans la console. C'est pourquoi un point d'accès peut sembler sain dans Postman mais échouer dans la console. Cet outil examine les en-têtes CORS réellement renvoyés par un serveur, afin que vous puissiez confirmer que le problème vient d'une configuration côté serveur plutôt que de votre code fetch. Collez votre point d'accès pour voir exactement quels en-têtes sont présents.

Une requête préliminaire est une requête OPTIONS automatique que le navigateur envoie avant la requête réelle, pour demander au serveur si l'appel effectif est autorisé. Cela se produit pour les requêtes « non simples » : des méthodes comme PUT, DELETE ou PATCH, des en-têtes de requête personnalisés, ou des types de contenu comme application/json. Le navigateur inclut Access-Control-Request-Method et Access-Control-Request-Headers, et le serveur doit répondre avec des valeurs Access-Control-Allow-Methods et Access-Control-Allow-Headers correspondantes, faute de quoi la requête réelle ne se déclenche jamais. Les requêtes GET et POST simples avec des en-têtes standards sautent cette étape. Comme les preflights sont invisibles dans la plupart des codes fetch, une poignée de main OPTIONS qui échoue est une cause fréquente et déroutante d'erreurs CORS. Ce testeur vous permet d'envoyer la requête en OPTIONS et d'examiner les méthodes et en-têtes autorisés que le serveur déclare, afin de vérifier directement le contrat de preflight au lieu de deviner à partir d'un message bloqué dans la console.

La spécification CORS interdit de combiner des requêtes avec identifiants et une origine en joker, et chaque navigateur applique cette règle. Lorsque vous envoyez des cookies ou des en-têtes d'autorisation en cross-origin, le serveur doit renvoyer une origine précise dans Access-Control-Allow-Origin — jamais l'astérisque générique. Si un serveur répond à la fois avec Access-Control-Allow-Credentials: true et un Access-Control-Allow-Origin réglé sur un joker, le navigateur rejette purement et simplement la réponse et votre requête échoue, même si les en-têtes semblent permissifs. La solution consiste à refléter l'origine exacte de la requête au lieu d'utiliser un joker, tout en gardant l'en-tête credentials réglé sur true. Cet outil signale exactement cette combinaison dangereuse comme une erreur dans son analyse CORS, afin que vous puissiez la repérer avant qu'elle ne casse un front-end authentifié. Testez votre point d'accès avec identifiants pour confirmer que l'origine est précise plutôt qu'en joker.

Une origine en joker permet à n'importe quel site sur Internet d'effectuer des requêtes cross-origin vers votre API et d'en lire la réponse, ce qui convient parfaitement à des données véritablement publiques comme des jeux de données ouverts, des API publiques en lecture seule, ou du JSON statique. Cela devient risqué dès que le point d'accès renvoie quelque chose de sensible ou qu'il est accessible avec les cookies d'un utilisateur, car un site malveillant pourrait alors l'appeler pour le compte d'un visiteur. En règle générale, restreignez Access-Control-Allow-Origin aux domaines précis qui ont légitimement besoin d'y accéder plutôt que de l'ouvrir à tout le monde, et n'associez jamais un joker avec des identifiants. Ce testeur affiche une origine en joker comme un avertissement et un domaine précis comme bon, afin que vous puissiez voir d'un coup d'œil à quel point un point d'accès est exposé. Testez votre URL ici pour vérifier si sa politique d'origine correspond à la sensibilité des données qu'il sert.

Access-Control-Max-Age indique au navigateur pendant combien de secondes il peut mettre en cache le résultat d'une requête préliminaire OPTIONS. Tant que ce cache est valide, le navigateur saute l'aller-retour supplémentaire et envoie directement la requête réelle, ce qui accélère nettement les applications qui déclenchent de nombreuses requêtes non simples vers le même point d'accès. Sans cela, le navigateur peut refaire un preflight à chaque appel, ajoutant de la latence. Les valeurs sont plafonnées par le navigateur — Chrome limite la mise en cache à quelques heures, quelle que soit la valeur indiquée — donc régler un nombre énorme n'apportera rien au-delà de ce plafond. L'absence de Max-Age signifie simplement qu'il n'y a aucune mise en cache du preflight. Cet outil lit l'en-tête et convertit les secondes brutes en minutes dans son analyse, afin que vous puissiez juger rapidement à quel point les preflights sont mis en cache de façon agressive. Testez votre point d'accès pour voir s'il définit un Max-Age utile.