Accueil → Aide

Erreur CORS lors d'un appel à une API IA depuis le navigateur

Appelez l'API depuis votre propre serveur, pas depuis la page. Le blocage CORS fait son travail : une requête que le navigateur peut faire est une requête que n'importe quel visiteur peut lire, y compris la clé dans son en-tête Authorization.

Ce que vous voyez

Pourquoi cela arrive

Il est tentant d'y voir un problème de configuration : ajouter une origine et livrer la fonctionnalité. Mais réfléchissez à ce qu'implique un appel réussi depuis le navigateur. La clé circule dans un en-tête que les outils de développement de l'utilisateur affichent en entier. Elle est dans le bundle si vous l'y avez intégrée, et dans l'onglet réseau sinon. Quiconque ouvre la page la possède.

Les clés divulguées ainsi ne sont pas un risque théorique. Les moteurs de recherche de code public les font remonter en permanence, et une clé volée sur une API facturée au token se transforme directement en facture de quelqu'un d'autre sur votre compte. C'est pourquoi la plupart des fournisseurs fixent un allow-origin restrictif plutôt que * : ce n'est pas un oubli, c'est un refus délibéré.

Le modèle proxy tient en trois ou quatre lignes de code serveur : votre page appelle votre backend, votre backend détient la clé et appelle le fournisseur. Cela vous donne aussi l'endroit où placer des limites de débit et de dépenses par utilisateur, que vous voulez de toute façon.

Vérifiez si c'est bien la cause

Demandez à l'endpoint quelles origines il autorise réellement :

curl -s -I -X OPTIONS 'YOUR_BASE_URL/chat/completions' \
  -H 'Origin: https://example.com' \
  -H 'Access-Control-Request-Method: POST' \
  | grep -i 'access-control'

Si Access-Control-Allow-Origin renvoie un domaine précis plutôt que *, les appels navigateur depuis votre origine ne fonctionneront pas, et aucune modification côté client n'y changera rien.

Comment le corriger

  1. Placez un endpoint sur votre propre backendVotre page envoie vers /api/chat sur votre propre domaine ; ce gestionnaire ajoute l'en-tête Authorization et transmet la requête. Aucun CORS en jeu, puisque le navigateur ne parle qu'à votre origine.
  2. N'utilisez jamais un préfixe public de build pour une cléLes variables NEXT_PUBLIC_, VITE_ et REACT_APP_ sont compilées dans le JavaScript que vous livrez. Une clé placée là est publiée, pas configurée.
  3. Renouvelez tout ce qui a déjà été livréSi une clé s'est trouvée dans un bundle déployé, considérez-la comme publique et remplacez-la. Renouveler ne coûte rien ; une facture sans plafond, si.
  4. Ajoutez des limites par utilisateur dans votre proxyDès que le trafic passe par votre propre gestionnaire, vous pouvez plafonner les dépenses par session. Appeler le fournisseur directement depuis le navigateur ne vous laisse aucun endroit où l'imposer.
L'hôte de l'API d'APICLAN n'autorise que https://apiclan.us comme origine, délibérément : les clés sont faites pour vivre sur un serveur. La configuration de la base URL pour les clients côté serveur est dans le démarrage rapide.

Voir aussi

Unexpected token '<' lors d'un appel à une API compatible OpenAI401 invalid API key : quand la clé semble correcte mais échoue quand même

Dernière vérification le 2026-10-01. Rédigé à partir de problèmes diagnostiqués sur une passerelle compatible OpenAI en production, pas compilé à partir d'autres sites.