CORS (Cross-Origin Resource Sharing) contrôle si un site web peut appeler une API d'une autre origine. Cet outil simule cette vérification du navigateur et t'explique, sans faire aucune requête réelle, si ton serveur autoriserait l'appel.
Renseigne l'Origine (l'URL de l'app qui fait la requête), la Méthode HTTP (GET, POST, PUT…) et colle les headers de réponse de ton serveur, un par ligne (par exemple Access-Control-Allow-Origin: *).
Il existe deux formes de requête cross-origin :
• Requête simple — avec GET, POST ou HEAD et des en-têtes basiques, le navigateur l'envoie directement puis vérifie si la réponse contient Access-Control-Allow-Origin.
• Avec preflight — avec des méthodes comme PUT, PATCH ou DELETE (ou des en-têtes personnalisés), le navigateur envoie d'abord une requête préalable de type OPTIONS pour demander la permission. L'outil signale automatiquement quand votre méthode nécessite un preflight.
Certaines méthodes et certains headers obligent le navigateur à envoyer d'abord une requête preflight avec la méthode OPTIONS. Si l'outil le détecte, ton serveur doit répondre à ce OPTIONS avec les headers CORS adéquats.
C'est l'en-tête indispensable : elle indique quelle origine peut lire la réponse.
• * — autorise n'importe quelle origine, mais ne fonctionne pas avec les identifiants (cookies).
• Une origine précise, p. ex. https://myapp.com — seulement cette origine, et elle doit coïncider exactement avec votre Origine (protocole + domaine + port).
Si cet en-tête manque, ou si la valeur ne correspond ni à * ni à votre origine, la requête est bloquée.
Liste les méthodes HTTP que le serveur accepte depuis une autre origine, séparées par des virgules (p. ex. GET, POST, PUT, DELETE). Elle est surtout pertinente pour le preflight. Si vous indiquez cet en-tête mais qu'il n'inclut pas votre méthode, l'outil le signale comme un problème et bloque la requête. Si vous ne le mettez pas, la méthode n'est pas vérifiée.
Énumère quels en-têtes de requête le client peut envoyer (p. ex. Content-Type, Authorization). Le navigateur l'exige lors du preflight quand votre requête envoie des en-têtes non standard. Si votre app envoie Authorization et qu'il n'apparaît pas ici, le navigateur bloquera l'appel.
Avec la valeur true, permet d'envoyer cookies et identifiants dans la requête cross-origin.
• Attention, piège important : les identifiants sont incompatibles avec Access-Control-Allow-Origin: *. Si vous utilisez des identifiants, l'origine doit être spécifique (p. ex. https://myapp.com), jamais *. Combiner les deux fait que le navigateur rejette la réponse.
Access-Control-Max-Age indique combien de secondes le navigateur peut mettre en cache la réponse du preflight (p. ex. 86400 = 24 h), pour ne pas répéter l'OPTIONS à chaque appel. L'outil l'inclut dans les en-têtes suggérés quand votre méthode nécessite un preflight. N'oubliez pas d'ajouter aussi Vary: Origin sur votre serveur quand vous renvoyez une origine précise, pour que les caches ne mélangent pas les réponses de différentes origines.
La bannière indique si la requête est autorisée ou bloquée et pourquoi. En dessous, chaque header CORS détecté est expliqué, les problèmes trouvés sont listés et un bloc de headers suggérés est proposé, prêt à copier sur ton serveur.
Access-Control-Allow-Origin*Permite cualquier origen (no funciona con credenciales)Access-Control-Allow-MethodsGET, POSTMétodos permitidos: GET, POSTAccess-Control-Allow-Origin: https://myapp.com Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS Access-Control-Allow-Headers: Content-Type, Authorization