Votre fetch vers l'API échoue avec une erreur CORS dans le navigateur mais la même requête passe très bien en curl. Que se passe-t-il et que faites-vous ?

CORS est appliqué par le navigateur, pas par le serveur, donc curl ne le voit jamais. La requête a probablement atteint le serveur et la réponse n'avait simplement pas d'en-tête d'origine autorisée que le navigateur accepte, ou un préflight OPTIONS a échoué. Regardez dans l'onglet réseau la requête OPTIONS et ses en-têtes de réponse, vérifiez que l'origine, les méthodes et les en-têtes autorisés couvrent votre appel, et rappelez-vous que les identifiants exigent une origine explicite plus allow credentials, jamais un joker.

La première chose que je dis, c'est que CORS est une règle du navigateur, pas du serveur, donc le succès de curl ne m'apprend rien à part que l'endpoint répond. Le navigateur a fait la requête, ou un préflight pour elle, et a refusé de me donner la réponse parce que les en-têtes n'autorisaient pas mon origine. Donc j'ouvre l'onglet réseau et je cherche d'abord une requête OPTIONS. Si elle est là et renvoie un 4xx, c'est le préflight lui-même qui échoue, en général parce que j'ai ajouté un en-tête personnalisé ou un content type JSON qui l'a fait sortir de la catégorie des requêtes simples, et que la liste d'en-têtes autorisés du serveur ne l'inclut pas. S'il n'y a pas de préflight, alors c'est la réponse réelle à qui il manque un en-tête d'origine autorisée correspondant à la mienne. La correction est côté serveur. En développement local, je passe par un proxy sur le serveur de dev pour que mon origine corresponde, mais je m'assure que les vrais en-têtes sont configurés aussi, sinon ça casse en préproduction. Et si l'appel envoie des cookies, le serveur doit renvoyer une origine précise plus allow credentials, puisqu'un joker est rejeté dans ce cas.