# Quand le navigateur bloque l'appel.

> Pourquoi le navigateur bloque un appel d'essai, comment ApiGlow diagnostique l'échec, et les issues : CORS côté API, proxy auto-hébergé, cookies.
>
> Source: https://apiglow.dev/fr/docs/cors/index.md


Les requêtes d'essai sont de simples `fetch` envoyés du navigateur du lecteur vers votre API. Rien ne transite par un serveur à nous, puisqu'il n'y en a pas — ce qui veut aussi dire que rien ne peut contourner la same-origin policy du navigateur. Si la doc et l'API vivent sur des origines différentes, **l'API doit autoriser l'origine de la doc via CORS**, sans quoi le navigateur bloque l'appel avant qu'il parte.

Quand un envoi échoue, ApiGlow le diagnostique dans l'interface : hors ligne, contenu mixte, CORS ou hôte injoignable. Le diagnostic est formulé au conditionnel (« le plus probable »), parce que le navigateur cache les détails à la page.

## Autoriser l'origine de la doc

Répondez au preflight avec un `Access-Control-Allow-Origin` nommant l'origine de la doc — ou `*` pour une API publique sans credentials — plus les méthodes et en-têtes que votre API utilise.

Si la doc est servie depuis l'origine de l'API elle-même, il n'y a pas de requête cross-origin et rien à configurer.

## Exposer les en-têtes qui valent d'être lus

Sans `Access-Control-Expose-Headers` côté API, le navigateur ne révèle qu'une courte liste d'en-têtes de réponse. Rate limit, pagination et dépréciation restent invisibles même quand l'appel réussit, et ApiGlow le signale. Exposez-les et les [diagnostics réseau](/fr/docs/try-it/) retrouvent leur matière.

`Timing-Allow-Origin` joue le même rôle pour les faits de transfert. Sans lui, une réponse cross-origin annonce des tailles à zéro, et les puces compression et cache ne s'affichent pas.

## Un proxy, si vous l'hébergez

`tryIt.proxyUrl` déclare un proxy CORS sous forme de gabarit, où `{{target}}` est remplacé par l'URL cible encodée :

```json
{ "tryIt": { "proxyUrl": "https://proxy.example.com/?url={{target}}" } }
```

L'app ne fournit aucun proxy et n'en fait tourner aucun. C'est un crochet pour celui que vous hébergez et en qui vous avez confiance. Une fois configuré, l'interface le propose sur les échecs CORS.

## L'auth par cookie de session

Pour une API authentifiée par un cookie de session httpOnly, le navigateur ne stocke ni n'envoie le cookie cross-origin par défaut. Posez `tryIt.requestCredentials: "include"` et respectez les trois exigences serveur qui viennent avec :

- `Access-Control-Allow-Credentials: true`
- un `Access-Control-Allow-Origin` explicite — `*` est rejeté
- un cookie `SameSite=None; Secure`

À noter : `"include"` est incompatible avec `Access-Control-Allow-Origin: *`. Le navigateur rejette le preflight même sans cookie à envoyer. Dans une installation [multi-spec](/fr/docs/multi-spec/), posez cette clé sur l'entrée de spec concernée plutôt qu'à la racine.

## OAuth2 ajoute deux exigences

Les flows dans le navigateur — Authorization Code + PKCE, et client credentials — demandent deux choses au serveur d'autorisation :

- Le `redirect_uri` envoyé est l'URL de la page hôte sans son hash, et doit être enregistré tel quel.
- Le token endpoint doit autoriser l'origine de la doc en CORS, comme tout appel d'essai.

## Ou éviter CORS tout court

`openapi.spec` porte le schéma dans la page et sort son téléchargement de l'équation. Héberger la doc sur l'origine de l'API sort le reste : même origine, pas de preflight, et le défaut `"same-origin"` fonctionne tel quel.