# CORS

> Mécanisme de sécurité des navigateurs (Cross-Origin Resource Sharing) qui bloque par défaut les requêtes JavaScript vers un autre domaine, sauf autorisation explicite du serveur distant.

- Auteur : Clément Hadrot
- Publié le : 2026-09-25
- Mis à jour le : 2026-09-25
- URL : https://wpmoderne.dev.wordpress-developpement.fr/lexique/cors/

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, POST
```

## Bon à savoir

- CORS est une protection appliquée par le navigateur, pas par le serveur : un outil comme `curl` ignore 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.