Testeur de requêtes CORS
Envoyez une vraie requête cross-origin depuis votre navigateur vers une API pour voir si CORS l'autorise. Explique quand un preflight est requis et lit les en-têtes.
Qu'est-ce que Testeur CORS ?
Ce testeur CORS envoie une véritable requête cross-origin depuis votre navigateur (avec la méthode, le Content-Type, l'en-tête personnalisé et le mode d'identifiants de votre choix) et indique si le navigateur laisse JavaScript lire la réponse. Avant l'envoi, il explique si la requête est « simple » ou nécessite un preflight OPTIONS, et pourquoi.
Comment utiliser Testeur CORS
- Saisissez l'URL de l'API à tester.
- Choisissez la méthode, un Content-Type facultatif et un en-tête personnalisé facultatif comme
Authorization: Bearer x. - Cochez « Envoyer les cookies / identifiants » si votre application utilise credentials: include.
- Lisez l'explication du preflight, puis cliquez sur Envoyer la requête de test.
- Si la requête est autorisée, examinez le statut et les en-têtes visibles par JavaScript ; si elle est bloquée, consultez la console du navigateur pour l'erreur CORS exacte.
Quand utiliser Testeur CORS
Utilisez-le pour vérifier si une API publique peut être appelée depuis une application navigateur, ou pour reproduire une erreur CORS avec des en-têtes précis. L'origine est toujours https://algokit.dev : un serveur qui n'autorise que votre propre domaine apparaîtra donc, à juste titre, bloqué ; testez depuis votre site pour une correspondance exacte. Il ne distingue pas les échecs CORS des erreurs réseau ou TLS, car le navigateur ne le révèle pas.
Comment fonctionne Testeur CORS
L'outil appelle fetch() avec mode: "cors" depuis l'origine de la page (https://algokit.dev), exactement comme le ferait votre propre code front-end. L'explication du preflight suit le standard Fetch : une méthode autre que GET/HEAD/POST, un Content-Type autre que form-urlencoded, multipart/form-data ou text/plain, ou tout en-tête personnalisé déclenche un preflight OPTIONS. Quand le navigateur bloque une réponse, il lève un TypeError générique et masque volontairement la raison ; l'outil vous invite donc à consulter la console.
Cas d'utilisation courants
- Vérifier qu'une API tierce envoie Access-Control-Allow-Origin avant de l'intégrer dans une SPA.
- Trouver quel en-tête de votre requête déclenche un preflight.
- Vérifier que credentials: include fonctionne (cela exige une origine précise, pas *).
- Voir quels en-têtes de réponse sont exposés à JavaScript via Access-Control-Expose-Headers.
Note de Sécurité
La requête part directement de votre navigateur vers l'URL saisie ; si les identifiants sont activés, vos cookies pour ce site sont aussi envoyés.
Questions Fréquentes
Pourquoi curl fonctionne-t-il alors que le navigateur échoue ?
CORS n'est appliqué que par les navigateurs. curl et les serveurs l'ignorent : une API peut donc fonctionner avec curl tout en restant illisible depuis une page web.
Qu'est-ce qui déclenche un preflight ?
Une méthode autre que GET, HEAD ou POST, un Content-Type non simple comme application/json, ou tout en-tête de requête personnalisé comme Authorization.
Peut-on utiliser Access-Control-Allow-Origin: * avec des cookies ?
Non. Avec des identifiants, le serveur doit renvoyer l'origine exacte et envoyer Access-Control-Allow-Credentials: true.