Aller au contenu

Testeur CORS

CORS Tester

Envoie la requête préalable qu’un navigateur enverrait depuis l’origine que vous indiquez, plus un GET portant cette origine, et explique selon les règles du standard Fetch quel en-tête a bloqué la requête.

Un échec CORS dans la console nomme l’en-tête qui manquait et presque jamais la raison, et la requête que le navigateur a réellement envoyée n’est pas celle qui est dans votre code. Ceci envoie le préflight qu’un navigateur enverrait depuis une origine que vous choisissez, puis un GET portant cette origine, et lit le résultat selon les règles du standard Fetch.

☁️ Passe par notre serveurcorshttpdebugweb

C’est notre serveur qui fait cette requête pour vous. Nous ne lui transmettons que l’URL, l’origine, la méthode et les noms d’en-tête que vous saisissez — aucun de vos cookies ni votre session ne part avec. Le serveur ne se connecte qu’à des adresses publiques et refuse les adresses privées et internes.

Un serveur envoie la pré-vérification (OPTIONS) qu’un navigateur enverrait, puis la requête elle-même, et le résultat est jugé selon les règles CORS du standard Fetch. La vraie requête est toujours un GET (ou un HEAD) : elle ne déclenche jamais un PUT ni un DELETE sur l’API de quelqu’un d’autre en votre nom.

Le schéma, l’hôte et le port de la page web qui fait l’appel.

application/json déclenche toujours une pré-vérification.

Comment s’en servir

  1. Entrez l’URL et l’origine

    L’origine est le site *depuis* lequel la requête viendrait : la page qui fait l’appel, pas l’API. Inverser les deux est la raison la plus fréquente pour laquelle un test contredit le navigateur.

  2. Ajoutez la méthode et les en-têtes que vous employez vraiment

    Un préflight n’a lieu que pour les requêtes non simples. C’est `Content-Type: application/json` ou un en-tête `Authorization` qui le déclenche, donc les omettre revient à tester une requête que vous ne faites jamais.

  3. Lisez quelle règle a échoué

    Le résultat nomme la vérification précise — origine non autorisée, méthode non listée, en-tête non listé, identifiants avec une origine générique — plutôt que de rapporter un échec générique.

Questions fréquentes

Cela passe ici mais le navigateur bloque quand même.

Vérifiez que la méthode, les en-têtes et le mode d’identifiants correspondent exactement à ce qu’envoie votre code, et que le serveur ne fait pas varier sa réponse selon le cookie ou l’agent utilisateur. Ceci tourne depuis un serveur, donc une réponse qui dépend d’une session que vous avez sera différente.

Pourquoi `Access-Control-Allow-Origin: *` ne marche-t-il pas avec les cookies ?

Le standard l’interdit. Avec `credentials: 'include'`, l’origine doit être renvoyée littéralement et `Access-Control-Allow-Credentials: true` doit être présent. Une origine générique avec des identifiants est rejetée par conception, pas à cause d’un bug.

Cela tourne-t-il dans mon navigateur ?

Non. Cela tourne depuis un serveur, parce qu’un navigateur ne peut pas émettre la requête que CORS bloque. Cela veut dire qu’il voit la réponse publique, sans vos cookies ni votre position réseau.

Puis-je tester une adresse interne ?

Non. La requête part d’un serveur qui ne peut pas atteindre votre réseau, et les adresses qui ne se résolvent qu’à l’intérieur échoueront quelle que soit leur configuration CORS.

À alimenter depuis

Ensuite

Ces outils acceptent ce que celui-ci produit : le résultat peut y aller directement.