01
Choisir l’Origin appelante
Saisissez protocole, hôte et port du frontend, pas l’URL de l’API. L’analyse locale accepte une Origin simulée ; le GET réel part obligatoirement de cette page.
HTTP / Débogage des requêtes
vérificateur CORSpour une réponse lisible
Collez la réponse réelle et, si nécessaire, celle d’OPTIONS. Le GET réseau reste manuel.
vérificateur CORS
En-têtes de la réponse réelle
En-têtes OPTIONS (facultatif)
Les en-têtes collés restent dans le navigateur ; aucune requête n'est envoyée.
Résultat
Collez des en-têtes de réponse pour commencer.
Conditions de requête
Cette Origin sert seulement à l'analyse locale. Le GET utilise l'Origin réelle de cette page.
Collez des en-têtes de réponse pour commencer.
Un journal serveur affiche 200 alors que fetch échoue ? Le vérificateur CORS distingue la livraison HTTP du droit de lecture accordé au JavaScript du navigateur.
Pour vérifier les en-têtes CORS, indiquez l’Origin de l’application, la méthode et les noms d’en-têtes. Une requête préliminaire peut nécessiter une seconde réponse OPTIONS ; le mode local n’interroge aucun serveur.
Pourquoi utiliser ce vérificateur CORS
Une réponse reçue ne devient pas automatiquement lisible.
Séparer livraison et lecture
Un GET simple peut atteindre le serveur et renvoyer 200. Si la réponse réelle n’autorise pas l’Origin, le navigateur la cache au script. Le vérificateur CORS ne confond pas succès HTTP et permission.
Isoler le contrôle OPTIONS
POST JSON ou Authorization peuvent imposer une requête préliminaire. Sans réponse OPTIONS, son résultat demeure inconnu. Ajoutez statut, méthodes et en-têtes autorisés pour trouver la condition refusée.
Suivre les deux contrôles du navigateur
02
Déterminer si OPTIONS est requis
application/json, Authorization ou une méthode non simple peuvent lancer un préflight. Les noms d’en-têtes suffisent pour cette classification. Sans réponse OPTIONS, ne concluez pas à un passage réussi.
03
Exporter seulement le résultat courant
Toute modification désactive copie et téléchargement du rapport ancien. L’analyse automatique attend 350 ms ; désactivez-la pour utiliser le bouton ou Ctrl/Cmd + Enter.
Lire chaque autorisation séparément
Comparer Origin et identifiants
Avec credentials: include, Allow-Origin: * échoue. Une Origin explicite demande aussi Allow-Credentials: true. L’en-tête Authorization et le mode credentials ne sont pas équivalents.
Contrôler méthode et en-têtes
Le testeur CORS examine le statut OPTIONS, Allow-Methods et Allow-Headers, puis nomme précisément la méthode ou l’en-tête manquant.
Voir exposition et cache
Expose-Headers indique les champs accessibles au script ; Vary: Origin mérite examen quand la réponse varie selon l’appelant. Une seule réponse ne prouve pas la réflexion d’origines arbitraires.
GET réel sur demande
Un clic envoie un GET sans identifiants depuis l’Origin de HeyUtils. Même un statut 404 peut rester lisible ; si fetch rejette, le navigateur cache statut et en-têtes.
Ce que le rapport ne peut pas certifier
- Texte collé, simulation locale
- Vérifier la configuration CORS avec des en-têtes collés ne prouve pas la réponse actuelle de l’API. Si OPTIONS est requis mais absent, le verdict reste non vérifié.
- Origin réelle non modifiable
- Le mode réseau du vérificateur CORS n’usurpe pas votre site et n’envoie ni POST, ni cookie, ni valeur d’en-tête personnel. Un succès même origine ne teste pas l’accès croisé.
- Pas de relais serveur ni de scan
- Aucune URL arbitraire n’est explorée depuis un proxy. Une ressource réservée à son origine peut légitimement omettre Allow-Origin ; ce seul fait ne révèle pas une faille.
- En-tête invisible ≠ absent
- Le script ne voit que les en-têtes autorisés par défaut ou par Expose-Headers. Utilisez les DevTools ou les journaux du serveur pour examiner le trafic complet.
Questions sur le vérificateur CORS
Pourquoi une requête échoue-t-elle avec une erreur CORS même si le serveur a répondu avec succès ?
Le serveur peut terminer la requête, puis le navigateur refuser de transmettre sa réponse à JavaScript. Vérifiez Allow-Origin dans la réponse réelle et OPTIONS séparément si un préflight est requis.
Quelle est la différence entre une requête simple et une requête avec préflight ?
Un GET simple part directement puis sa réponse est contrôlée. POST JSON ou en-têtes personnalisés exigent parfois un OPTIONS préalable qui autorise Origin, méthode et noms d’en-têtes.
Vérifier les en-têtes CORS ici envoie-t-il mes données à un serveur ?
L’analyse locale ne transmet pas les en-têtes collés. En mode navigateur, seul un clic sur Lancer le GET envoie une requête sans identifiants à l’URL choisie.
CORS protège-t-il une API contre les requêtes malveillantes ?
Non. CORS limite la lecture depuis JavaScript dans le navigateur. Authentification et autorisation doivent rester côté serveur ; curl et Postman n’appliquent pas cette règle de lecture.
Pourquoi Access-Control-Allow-Origin: * ne fonctionne-t-il pas avec credentials: include ?
Pour credentials: include, le serveur doit renvoyer l’Origin exacte et Allow-Credentials: true. Un joker Allow-Origin: * ne peut pas exposer la réponse au script.
Un autre cas à expliquer ?
Essayer le vérificateur CORS sur des preuves réelles
Copiez depuis les DevTools la réponse réelle et, au besoin, OPTIONS. Le vérificateur CORS sépare les deux décisions avant toute modification du serveur.
Analyse locale initiale ; GET réseau seulement sur clic.