Un script chargé sur site-a.fr qui tente d’appeler discrètement une API sur site-b.fr via fetch() se heurte, par défaut, à un mur : le navigateur refuse la réponse tant que site-b.fr n’a pas explicitement dit « j’accepte les requêtes venues de site-a.fr ». Cette autorisation passe par des en-têtes HTTP spécifiques, envoyés par le serveur distant, pas par le site appelant.
Rencontres fréquentes avec WordPress
L’API REST de WordPress (/wp-json/) n’autorise pas CORS par défaut : un site JavaScript hébergé ailleurs qui tente de l’interroger obtiendra une erreur dans la console, sauf si le thème ou une extension ajoute l’en-tête Access-Control-Allow-Origin via le filtre rest_pre_serve_request. C’est un point de blocage classique pour les architectures « headless » où un front React consomme l’API WordPress depuis un autre nom de domaine.
Exemple
Access-Control-Allow-Origin: https://app.exemple.fr
Access-Control-Allow-Methods: GET, POSTBon à savoir
- CORS est une protection appliquée par le navigateur, pas par le serveur : un outil comme
curlignore totalement cette restriction, ce qui explique pourquoi « ça marche en ligne de commande mais pas dans le navigateur ». - Ouvrir
Access-Control-Allow-Origin: *(tout autoriser) sur une API qui gère des données sensibles est une mauvaise pratique : mieux vaut lister précisément les origines de confiance. - Une erreur CORS dans la console ne signifie pas forcément que le serveur est en panne : la requête peut très bien avoir abouti côté serveur, seule la lecture de la réponse est bloquée côté navigateur.