Texte & documents
Nombres & calcul
Données & formats
Sécurité
Développement & DevOps
Intelligence artificielle
Finances
Santé et bien-être
Productivité
Jeux et divertissement
Multimédia & design
Entreprise
Guide d'utilisation
Ce que c'est et à quoi ça sert

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.

Ce qu'il faut saisir

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: *).

Requête simple vs preflight

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.

Preflight (OPTIONS)

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.

Access-Control-Allow-Origin

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.

Access-Control-Allow-Methods

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.

Access-Control-Allow-Headers

É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.

Access-Control-Allow-Credentials

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 et Vary

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.

Comment lire le résultat

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.

CORS ExplainerAnalysez les en-têtes CORS de votre serveur
CORS ExplainerAnalysez et expliquez les en-têtes CORS de votre serveur
URL de l'app qui fait la requête

Márcalo si tu código usa credentials: 'include' (o withCredentials). Cambia las reglas: el origen ya no puede ser *, los comodines dejan de valer y el servidor tiene que responder Access-Control-Allow-Credentials: true.

Las de la PETICIÓN, no las de la respuesta. Son las que deciden si el navegador manda antes un OPTIONS, y las que «Access-Control-Allow-Headers» tiene que cubrir.

CORS permitido correctamente
El navegador mandará antes una petición OPTIONS (preflight), por el Content-Type application/json. Tu servidor tiene que contestar también a ESE OPTIONS, no solo a la petición real.

En-têtes CORS trouvés

Access-Control-Allow-Originhttps://myapp.comPermite solo el origen: https://myapp.com
Access-Control-Allow-MethodsPOSTMétodos permitidos: POST
Access-Control-Allow-HeadersContent-TypeCabeceras permitidas en la petición: Content-Type

En-têtes suggérés pour votre serveur

Access-Control-Allow-Origin: https://myapp.com
Vary: Origin
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 86400
Esto se decide sobre las cabeceras que pegues, sin salir a la red — por eso vale también para una API local o privada. Si quieres lanzar la petición de VERDAD y ver si tu servidor llegó a contestar, está el Banco de trabajo de APIs.