Erreur « has been blocked by CORS policy » sur WordPress : causes, solutions et bonnes pratiques

Sommaire de l'article

Introduction

L’erreur « has been blocked by CORS policy » est un problème courant rencontré par les administrateurs de sites WordPress lorsqu’une page tente d’accéder à des ressources hébergées sur un autre domaine (API, scripts, polices, images, CDN, sous-domaine, etc.). Cette erreur n’est pas propre à WordPress : elle provient du navigateur, qui applique le mécanisme de sécurité appelé CORS (Cross-Origin Resource Sharing).

En pratique, cela signifie que le navigateur a bloqué une requête parce que le serveur cible n’a pas renvoyé les en-têtes CORS attendus (par exemple Access-Control-Allow-Origin). WordPress n’est qu’un élément de la pile : le problème se situe toujours du côté du serveur qui fournit la ressource ou d’un intermédiaire (CDN, proxy, cache, plugin de sécurité).

Cet article explique en détail :

ce qu’est réellement CORS et pourquoi l’erreur apparaît sur un site WordPress ;
les principaux scénarios où l’on voit « has been blocked by CORS policy » dans la console ;
comment diagnostiquer précisément l’origine du blocage ;
les méthodes sûres pour corriger l’erreur (Apache, Nginx, plugins, proxy, API externes, sous-domaines, CDN) ;
les bonnes pratiques pour éviter de graves problèmes de sécurité en « ouvrant trop largement » CORS.

L’objectif est de vous permettre de résoudre durablement ces erreurs CORS sur votre site WordPress, sans nuire à la sécurité ni aux performances.

Rappels essentiels : CORS et WordPress

Qu’est-ce que CORS ?

CORS signifie « Cross-Origin Resource Sharing » ou « Partage des ressources entre origines différentes ». Il s’agit d’un mécanisme de sécurité intégré aux navigateurs qui contrôle les requêtes HTTP effectuées entre origines différentes. Une origine est définie par le triplet schéma (http/https) + domaine + port.

Par défaut, un navigateur n’autorise pas une page chargée depuis https://www.monsite.com à effectuer librement des requêtes JavaScript vers https://api.autredomaine.com. Pour que ces requêtes soient autorisées, le serveur cible doit répondre avec des en-têtes CORS appropriés, dont le plus connu est :

Access-Control-Allow-Origin: https://www.monsite.com (ou une autre origine autorisée).

Si ces en-têtes sont absents, incomplets ou incohérents, le navigateur affiche un message du type :

Access to fetch at 'https://api.autredomaine.com' from origin 'https://www.monsite.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present...

Point crucial : c’est le navigateur qui bloque la réponse pour des raisons de sécurité, non WordPress. WordPress peut cependant être à l’origine de la requête (thème, plugin, script personnalisé) et doit donc être pris en compte dans le diagnostic.

CORS et WordPress : où se situe le problème ?

Sur un site WordPress, l’erreur « has been blocked by CORS policy » apparaît généralement dans les cas suivants :

un thème ou un plugin exécute du JavaScript (AJAX, fetch, XMLHttpRequest) vers une API externe ou un autre domaine ;
les fichiers statiques (images, JS, CSS, polices) sont servis depuis un CDN ou un sous-domaine différent ;
l’interface front (par exemple en React, Vue, Angular) est hébergée sur un domaine distinct du back-end WordPress (architecture « headless ») ;
un plugin de sécurité, un pare-feu d’application web (WAF), un proxy ou un CDN modifie ou supprime les en-têtes CORS.

Cela signifie que WordPress ne « bloque » rien directement. Le rôle de WordPress est plutôt de :

générer le code (thème, plugins, JS) qui déclenche la requête multi-origine ;
éventuellement fournir une API (REST API WordPress, endpoints personnalisés) qui doit être correctement configurée côté serveur pour accepter CORS.

Principales causes de l’erreur CORS sur un site WordPress

1. Ressources externes (API, widgets, scripts tiers)

Vous pouvez rencontrer l’erreur « has been blocked by CORS policy » lorsque votre site WordPress charge :

des widgets tiers (cartes, formulaires, chat en ligne, scripts marketing) ;
des API REST pour récupérer des données (produits, posts, statistiques, etc.) ;
des scripts analytiques ou des bibliothèques hébergées sur un autre domaine.

Si le fournisseur externe ne renvoie pas les bons en-têtes CORS, le navigateur bloque la réponse. Dans ce cas, modifier la configuration de votre propre serveur ne suffit pas toujours : il peut être nécessaire de contacter le fournisseur ou de mettre en place un proxy côté serveur.

2. Plugins ou thèmes WordPress mal configurés

De nombreux thèmes et plugins WordPress exécutent des requêtes AJAX ou des appels vers des services externes. Parmi les causes fréquentes :

un plugin qui appelle une API sur un domaine différent sans prévoir la configuration CORS côté serveur ;
un thème qui charge des polices, des images ou du JavaScript depuis un autre domaine ou un CDN ;
un constructeur de pages (page builder) qui intègre des iframes ou des widgets distants.

Lorsque l’erreur est liée à un plugin ou à un thème précis, la solution consiste souvent à :

identifier quel composant déclenche la requête multi-origine ;
vérifier sa documentation : certains proposent des réglages CORS ou des options pour déclarer les origines autorisées ;
adapter la configuration serveur pour ajouter les en-têtes nécessaires aux réponses concernées.

3. Hébergement, serveur web ou proxy mal configurés

Les paramètres CORS sont gérés au niveau du serveur (Apache, Nginx, reverse proxy, CDN, etc.). Une mauvaise configuration peut :

ne pas envoyer du tout les en-têtes CORS requis ;
envoyer des en-têtes uniquement sur certains types de réponses (par exemple uniquement sur les fichiers statiques, mais pas sur les réponses PHP ou API) ;
définir plusieurs valeurs contradictoires pour Access-Control-Allow-Origin ;
supprimer ou écraser les en-têtes ajoutés par WordPress ou par un plugin.

Il est donc essentiel de vérifier la configuration globale du serveur et les éventuelles couches intermédiaires :

configuration Apache (.htaccess, vhosts, modules) ;
configuration Nginx (blocs server, location) ;
services de cache ou de proxy (Varnish, reverse proxy, load balancer) ;
CDN (Cloudflare, etc.), qui peuvent filtrer ou modifier les en-têtes.

4. Sous-domaines, multisite, environnement headless

Une autre source fréquente de CORS sur WordPress concerne les architectures avancées :

multisite avec plusieurs sous-domaines ;
front-end séparé (React, Vue, Next.js, Nuxt, etc.) sur un domaine différent de WordPress ;
API WordPress utilisée depuis une application mobile ou une WebApp externe.

Dans ces cas, l’application cliente (front-end) appelle l’API WordPress via fetch ou XMLHttpRequest. Si le serveur WordPress ne répond pas avec des en-têtes CORS autorisant explicitement l’origine du client, les requêtes sont bloquées. Il peut être tentant d’autoriser * comme origine, mais ce n’est pas toujours recommandé, en particulier lorsqu’il y a authentification ou envoi de cookies.

Impact de l’erreur « has been blocked by CORS policy » sur un site WordPress

Fonctionnalités cassées et expérience utilisateur dégradée

L’impact le plus visible est fonctionnel :

widgets ou formulaires qui ne s’affichent pas ;
cartes, carrousels, modules de recherche ou de filtre qui ne se chargent pas ;
fonctionnalités AJAX (ajout au panier, chargement infini, commentaires dynamiques) qui échouent ;
polices ou fichiers CSS/JS non chargés, provoquant des défauts d’affichage ou des erreurs JavaScript.

Tout cela se traduit par une expérience utilisateur dégradée, une augmentation possible du taux de rebond et, indirectement, un impact négatif sur les performances globales et le référencement naturel si des fonctionnalités clés ne fonctionnent pas.

Conséquences possibles sur la sécurité

Un point souvent négligé : une configuration CORS incorrecte peut ouvrir des failles de sécurité. Par exemple :

autoriser Access-Control-Allow-Origin: * sur des endpoints sensibles peut permettre à des sites malveillants d’interagir avec votre API ;
autoriser trop largement les méthodes (PUT, DELETE, etc.) ou les en-têtes personnalisés sans authentification appropriée augmente les risques d’abus ;
une mauvaise gestion des requêtes préliminaires (OPTIONS, préflight) peut conduire à des incohérences de sécurité.

L’objectif n’est donc pas seulement de « faire disparaître l’erreur », mais de configurer CORS de manière maîtrisée, en accord avec les bonnes pratiques de sécurité.

Comment diagnostiquer une erreur CORS sur WordPress

1. Inspecter la console du navigateur et l’onglet Réseau

Commencez toujours par ouvrir les outils de développement du navigateur (Chrome, Firefox, Edge) et regardez :

dans l’onglet Console, le message complet « has been blocked by CORS policy » ;
dans l’onglet Réseau, la requête qui échoue (filtrez par XHR/fetch si nécessaire).

Dans les détails de la requête, examinez :

l’URL exacte de la ressource appelée ;
l’origine (domaine de la page appelante) ;
les en-têtes de requête (méthode, en-têtes personnalisés, présence ou non de cookies) ;
les en-têtes de réponse, en particulier Access-Control-Allow-Origin, Access-Control-Allow-Methods et Access-Control-Allow-Headers.

Si l’en-tête Access-Control-Allow-Origin est absent, ou si sa valeur ne correspond pas à l’origine de la page, le diagnostic est confirmé : la ressource ne permet pas l’accès depuis ce domaine.

2. Identifier qui déclenche la requête (thème, plugin, script)

Une fois la requête incriminée repérée, identifiez :

quel fichier JS l’a générée (souvent indiqué dans la pile d’appels de la console) ;
si ce fichier appartient à un plugin, un thème ou à votre code personnalisé ;
si la requête provient d’un widget externe intégré via un script tiers ou une iframe.

Un bon moyen de tester est de désactiver temporairement les plugins non essentiels et de repasser au thème par défaut, afin de voir si l’erreur persiste. Quand l’erreur disparaît après la désactivation d’un plugin précis, vous avez identifié un début de piste.

3. Vérifier si le serveur cible permet CORS

Pour les ressources externes (API d’un tiers, CDN que vous ne contrôlez pas complètement), il est important de vérifier si le serveur cible renvoie les en-têtes CORS attendus. Vous pouvez :

tester la même URL avec un outil comme curl ou Postman pour voir les en-têtes de réponse ;
consulter la documentation de l’API ou du service pour vérifier leur politique CORS ;
contactez le support technique du fournisseur pour demander l’ajout de votre domaine comme origine autorisée.

4. Prendre en compte les couches de cache, CDN et sécurité

Les solutions de cache, de CDN et de sécurité peuvent interférer avec les en-têtes CORS :

un plugin de cache peut servir une page depuis le cache sans certains en-têtes ;
un CDN peut modifier ou supprimer des en-têtes dans ses réponses ;
un WAF ou un pare-feu peut bloquer certaines méthodes (par exemple OPTIONS pour le préflight).

Lors du diagnostic, pensez à :

vider les caches (plugin, serveur, CDN) ;
désactiver temporairement les règles de sécurité trop agressives pour tester ;
tester en accès direct au serveur (sans passer par le CDN) lorsque c’est possible.

Comment corriger l’erreur CORS sur WordPress

1. Ajouter ou ajuster les en-têtes CORS côté serveur (Apache, Nginx)

La manière la plus robuste de corriger un problème CORS sur un site WordPress est d’ajouter les en-têtes au niveau du serveur, afin qu’ils soient envoyés de manière cohérente sur les ressources concernées.

Exemple pour Apache via .htaccess

Dans un hébergement WordPress courant utilisant Apache, vous pouvez ajouter des directives dans le fichier .htaccess à la racine du site. Avant toute modification, faites toujours une sauvegarde de ce fichier.

Exemple de configuration de base :

 Header set Access-Control-Allow-Origin "https://www.votredomaine.com" Header set Access-Control-Allow-Methods "GET, POST, OPTIONS" Header set Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept, Authorization"

Points importants :

remplacez https://www.votredomaine.com par l’origine exacte autorisée (évitez * sauf pour des ressources publiques sans cookies ni authentification) ;
adaptez la liste des méthodes aux besoins réels (n’ajoutez PUT ou DELETE que si nécessaire) ;
adaptez la liste des en-têtes autorisés à ceux utilisés par vos requêtes.

Selon votre configuration, vous pouvez cibler seulement certains types de fichiers ou endpoints (par exemple uniquement vos endpoints d’API), plutôt que d’ajouter ces en-têtes sur tout le site.

Exemple pour Nginx

Pour un site WordPress servi par Nginx, la configuration se fait généralement dans le bloc server ou location. Par exemple :

location / { add_header 'Access-Control-Allow-Origin' 'https://www.votredomaine.com' always; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always; add_header 'Access-Control-Allow-Headers' 'Origin, X-Requested-With, Content-Type, Accept, Authorization' always; if ($request_method = 'OPTIONS') { return 204; }
}

Comme pour Apache, adaptez l’origine, les méthodes et les en-têtes à votre cas réel. Nginx nécessite un rechargement ou un redémarrage du service après modification de la configuration.

2. Utiliser un plugin WordPress pour gérer CORS

Si vous n’avez pas la main sur la configuration du serveur (hébergements mutualisés, panneaux d’administration limités), vous pouvez utiliser un plugin spécialisé pour ajouter des en-têtes CORS au niveau de WordPress.

Le principe de ces plugins est généralement :

ajouter des en-têtes CORS à chaque réponse HTTP générée par WordPress ;
vous permettre de définir la ou les origines autorisées ;
choisir les méthodes et les en-têtes autorisés ;
parfois restreindre CORS à certaines routes (par exemple l’API REST).

Attention toutefois :

si le serveur ou un CDN supprime ou écrase les en-têtes, le plugin ne suffira pas ;
des doublons ou contradictions entre les en-têtes ajoutés par un plugin et ceux définis au niveau serveur peuvent créer d’autres erreurs.

3. Mettre en place un proxy côté serveur pour les API externes

Lorsque vous n’avez aucun contrôle sur le serveur cible (par exemple une API tierce qui ne supporte pas CORS pour votre domaine), une solution efficace consiste à utiliser un proxy côté serveur dans WordPress.

Le principe :

votre front-end (même domaine que WordPress) envoie une requête à un endpoint WordPress (par exemple une route personnalisée de l’API REST) ;
ce endpoint, côté serveur, appelle l’API externe et récupère la réponse ;
WordPress renvoie ensuite la réponse au navigateur avec ses propres en-têtes CORS, que vous contrôlez.

De cette façon, pour le navigateur, il ne s’agit plus d’une requête multi-origine vers un domaine externe, mais d’une requête vers le même domaine que la page. Vous contournez ainsi les limitations CORS du fournisseur externe, tout en gardant un contrôle sur la sécurité et le cache.

4. Configurer correctement les API et sous-domaines WordPress

Dans les cas où vous utilisez :

un front-end séparé (SPA, PWA, application mobile) ;
un sous-domaine spécifique pour les médias ou l’API ;
un multisite avec des domaines ou sous-domaines différents,

il est recommandé de :

définir explicitement la liste des origines clientes autorisées :

Access-Control-Allow-Origin: https://app.votredomaine.com

gérer correctement les requêtes préliminaires (OPTIONS) : le serveur doit y répondre avec les bons en-têtes et un code adapté (souvent 204) ;
éviter l’utilisation de * si des cookies ou des jetons d’authentification sont en jeu ;
documenter la politique CORS dans vos propres API, afin que les clients sachent comment les utiliser.

5. Réduire au minimum les dépendances externes

Une approche complémentaire pour limiter les problèmes CORS est de réduire la dépendance aux ressources externes lorsqu’elles ne sont pas indispensables. Par exemple :

héberger localement certaines bibliothèques JavaScript plutôt que de les charger depuis des CDN tiers ;
utiliser un CDN bien intégré à votre stack, configuré avec des en-têtes CORS cohérents ;
regrouper ou remplacer certains widgets tiers par des solutions natives à votre site.

Cela améliore non seulement la stabilité par rapport à CORS, mais aussi les performances (temps de chargement) et la maîtrise globale de votre infrastructure.

Bonnes pratiques de configuration CORS pour WordPress

1. N’autorisez pas « * » par défaut sur tout le site

Il est techniquement possible d’autoriser toutes les origines avec :

Access-Control-Allow-Origin: *

Cependant, cette approche doit être utilisée avec prudence. Elle est acceptable pour :

des ressources totalement publiques ne manipulant pas de données sensibles ;
des fichiers statiques (polices, images, JS, CSS) qui peuvent être partagés sans risque ;
des endpoints d’API ne renvoyant que des informations anonymes ou publiques.

En revanche, pour tout ce qui touche à l’authentification, aux profils utilisateurs, aux données de commande ou à des informations internes, il est préférable de limiter les origines autorisées à une liste précise.

2. Adaptation fine par type de ressource

Une bonne configuration CORS sur WordPress n’est pas forcément globale. Vous pouvez par exemple :

autoriser largement CORS sur un sous-domaine dédié aux médias (images, polices) ;
appliquer une politique plus restrictive sur l’API REST ou les endpoints personnalisés ;
définir des règles spécifiques par dossier ou par extension dans Apache ou Nginx.

Cela permet de concilier compatibilité (moins de problèmes CORS visibles par les utilisateurs) et sécurité (pas d’ouverture inutile sur des zones sensibles).

3. Prendre en compte les préflights (OPTIONS)

Les requêtes dites « complexes » (méthodes autres que GET/POST simples, en-têtes personnalisés, envoi de JSON, etc.) nécessitent un préflight : le navigateur envoie d’abord une requête OPTIONS pour demander au serveur s’il autorise la requête principale.

Pour que cette étape réussisse :

le serveur doit répondre à OPTIONS avec un code 200 ou 204 ;
la réponse doit contenir des en-têtes Access-Control-Allow-* cohérents ;
les méthodes et en-têtes déclarés doivent inclure ceux qui seront utilisés dans la requête réelle.

Une mauvaise gestion des préflights est une cause fréquente d’erreurs CORS, même lorsque l’en-tête Access-Control-Allow-Origin semble correct sur les réponses principales.

4. Tester après chaque modification

Après avoir modifié la configuration serveur, installé un plugin ou mis en place un proxy, testez systématiquement :

vidangez le cache du navigateur et les caches serveur/CDN ;
rafraîchissez la page en mode navigation privée ;
contrôlez les requêtes dans l’onglet Réseau pour vérifier la présence et la valeur des en-têtes CORS ;
testez depuis différents navigateurs et, si possible, différents environnements.

Outils utiles pour diagnostiquer et suivre les erreurs CORS

Outils de débogage navigateur

Google Chrome DevTools : onglets Console et Réseau pour identifier les requêtes bloquées, consulter les en-têtes et les réponses, analyser les préflights.
Firefox Developer Tools : propose également des informations détaillées sur les requêtes CORS, avec des messages d’erreur explicites.
Outils de développement Edge/Safari : similaires pour inspecter les requêtes HTTP et les erreurs liées à CORS.

Outils de test HTTP

curl : permet de tester rapidement un endpoint et de voir les en-têtes renvoyés par le serveur ;
Postman ou outils équivalents : utiles pour tester les endpoints d’API sans passer par le navigateur, afin de distinguer un problème CORS d’un problème de serveur ou de logique applicative.

Outils d’analyse et de suivi SEO

Les erreurs CORS ne sont pas directement des erreurs SEO, mais elles peuvent se répercuter sur l’accessibilité et l’expérience utilisateur. Pour garder un site WordPress performant et sain :

Google Search Console : permet de surveiller les erreurs d’exploration, les problèmes d’indexation et les performances de vos pages ;
Outils d’audit de site (comme certains crawlers SEO) : utiles pour détecter les ressources non chargées, les scripts cassés ou les éléments bloqués qui peuvent être liés à CORS.

Conseils pratiques pour un site WordPress performant et stable côté CORS

1. Documenter votre architecture

Notez clairement :

les domaines et sous-domaines utilisés par votre site (front, back, médias, API, CDN) ;
les services externes critiques (API de paiement, CRM, marketing, etc.) ;
les plugins ou thèmes qui font des appels multi-origines.

Cette cartographie vous aidera à anticiper les besoins CORS et à repérer rapidement l’origine d’une erreur.

2. Choisir des plugins et thèmes de qualité

Lors du choix de vos extensions WordPress :

privilégiez les plugins bien maintenus, régulièrement mis à jour et disposant d’une documentation claire ;
vérifiez si le plugin mentionne la gestion de CORS ou d’API externes ;
évitez d’accumuler plusieurs plugins qui modifient les en-têtes ou ajoutent des fonctionnalités de sécurité sans coordination.

3. Surveiller régulièrement la console du navigateur

Intégrez la vérification de la console et de l’onglet Réseau dans vos routines de tests :

après chaque mise à jour de plugin, thème ou WordPress ;
après l’ajout d’un nouveau service externe (widget, API, script) ;
après une modification d’hébergement, de configuration serveur ou de CDN.

4. Garder un équilibre entre ouverture et sécurité

Pour un site WordPress qui exploite de nombreuses ressources externes, il est tentant de tout « ouvrir » pour ne plus voir d’erreur CORS. Pourtant, la bonne approche consiste à trouver un équilibre :

autoriser seulement les origines légitimes ;
limiter les méthodes et en-têtes au strict nécessaire ;
ne pas exposer d’endpoints sensibles sans authentification robuste ;
utiliser des proxys serveur lorsque les politiques CORS des tiers sont trop restrictives.

Conclusion : gérer efficacement « has been blocked by CORS policy » sur WordPress

L’erreur « has been blocked by CORS policy » sur un site WordPress est le symptôme d’un problème de configuration entre le navigateur, l’origine de la page et le serveur qui fournit la ressource demandée. Elle ne vient pas d’un « blocage spécial de WordPress », mais d’un mécanisme de sécurité standard côté navigateur.

Pour la corriger efficacement, il est essentiel de :

comprendre le rôle de CORS et des en-têtes comme Access-Control-Allow-Origin ;
diagnostiquer précisément la requête concernée via les outils de développement ;
ajuster la configuration de votre serveur (Apache, Nginx, proxy, CDN) ou de vos plugins pour envoyer les bons en-têtes ;
recourir, si nécessaire, à un proxy côté serveur lorsque vous dépendez d’API externes non configurables ;
maintenir une politique CORS cohérente et sécurisée, adaptée à votre architecture WordPress.

En appliquant ces principes, vous pouvez non seulement faire disparaître les messages « has been blocked by CORS policy » de votre console, mais surtout garantir un site WordPress fiable, sécurisé et performant, capable de s’intégrer correctement avec les services et API dont il dépend.