« Blocked by CORS policy » : comprendre et corriger l’erreur

Ce que le message vous dit exactement

Le blocage vient du navigateur, pas du serveur : la requête est bel et bien partie, le serveur a bel et bien répondu, mais le navigateur refuse de livrer la réponse au JavaScript de la page faute d'autorisation. C'est pourquoi la requête fonctionne parfaitement avec curl ou Postman, qui n'appliquent aucune politique d'origine — un détail qui déroute beaucoup de développeurs.

Le message précise la nature du refus. « No 'Access-Control-Allow-Origin' header is present » signifie que le serveur n'a rien autorisé du tout. « The value of the header does not match the origin » indique une autorisation existante mais pour une autre origine — attention, la comparaison porte sur le schéma, le domaine et le port exacts : https://exemple.com et https://www.exemple.com sont deux origines distinctes. Enfin, « Response to preflight request doesn't pass » signale que la requête de contrôle préalable, envoyée en OPTIONS, a échoué.

Ce contrôle préalable se déclenche dès que la requête sort du cadre le plus simple : méthode PUT, PATCH ou DELETE, en-tête Authorization ou Content-Type: application/json. Le navigateur envoie alors d'abord une requête OPTIONS, à laquelle le serveur doit répondre avec les méthodes et en-têtes autorisés. Un serveur qui renvoie 404 ou 405 sur OPTIONS provoque un échec CORS même si sa configuration semble correcte par ailleurs.

La configuration correcte, côté serveur

Le principe : autorisez explicitement les origines dont vous avez besoin, et elles seules. Pour une API publique en lecture seule, sans authentification ni cookie, l'astérisque est acceptable. Dès qu'il y a authentification, il est à proscrire — et de toute façon inopérant : le navigateur refuse la combinaison de l'astérisque et des identifiants.

Pour une API authentifiée, la règle est simple : une liste blanche d'origines autorisées, une vérification que l'origine reçue en fait partie, et le renvoi de cette origine précise dans l'en-tête de réponse. Ajoutez l'en-tête Vary: Origin, sans lequel un cache ou un CDN peut servir à un visiteur la réponse autorisée pour une autre origine.

Le piège à éviter absolument est le renvoi automatique de l'origine reçue sans vérification, combiné à l'autorisation des identifiants : cela revient à autoriser n'importe quel site du web à lire les données de vos utilisateurs connectés. C'est une faille classique, régulièrement exploitée, et détectée comme telle par les audits de sécurité.

const ORIGINES = ['https://site.exemple.com', 'https://admin.exemple.com'];

app.use((req, res, next) => {
  const origine = req.headers.origin;
  if (ORIGINES.includes(origine)) {
    res.setHeader('Access-Control-Allow-Origin', origine);
    res.setHeader('Access-Control-Allow-Credentials', 'true');
    res.setHeader('Vary', 'Origin');
  }
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  if (req.method === 'OPTIONS') return res.sendStatus(204);
  next();
});

Header always set Access-Control-Allow-Origin "https://site.exemple.com"
Header always set Access-Control-Allow-Methods "GET, POST, OPTIONS"
Header always set Access-Control-Allow-Headers "Content-Type, Authorization"
Header always append Vary "Origin"

location /api/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin "https://site.exemple.com";
        add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";
        add_header Access-Control-Allow-Headers "Content-Type, Authorization";
        add_header Access-Control-Max-Age 86400;
        return 204;
    }
    add_header Access-Control-Allow-Origin "https://site.exemple.com" always;
    add_header Vary Origin always;
}

<?php
$origines = ['https://site.exemple.com'];
$origine = $_SERVER['HTTP_ORIGIN'] ?? '';
if (in_array($origine, $origines, true)) {
    header("Access-Control-Allow-Origin: $origine");
    header('Access-Control-Allow-Credentials: true');
    header('Vary: Origin');
}
if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') { http_response_code(204); exit; }

En développement local : le proxy plutôt que la rustine

En local, la bonne pratique n'est pas d'ouvrir le serveur de production mais de faire passer les requêtes par le proxy de développement intégré à votre outil de build (Vite, webpack dev server, Angular CLI). Le navigateur ne voit alors qu'une seule origine, et la question CORS disparaît — sans modifier la configuration de production.

Évitez en revanche les extensions de navigateur qui « désactivent CORS » et les lancements de Chrome avec la sécurité web désactivée : ils masquent le problème sur votre poste, laissent la vraie configuration cassée pour tous les autres, et vous exposent personnellement pendant toute la session de navigation.

Vérifier la configuration

Testez le contrôle préalable directement : une requête OPTIONS envoyée avec l'en-tête Origin doit répondre 204 ou 200 et renvoyer les en-têtes d'autorisation attendus. Testez ensuite avec une origine volontairement non autorisée : le serveur ne doit alors renvoyer aucune autorisation. Si une origine arbitraire est acceptée, votre configuration est trop permissive.

Un scan externe vérifie précisément ce point parmi ses contrôles : il détecte les configurations CORS dangereuses, en particulier le renvoi automatique de l'origine avec autorisation des identifiants, et l'astérisque combiné à une API authentifiée.

curl -i -X OPTIONS https://api.exemple.com/ressource \
  -H "Origin: https://site.exemple.com" \
  -H "Access-Control-Request-Method: POST"

curl -sI https://api.exemple.com/ressource -H "Origin: https://attaquant.example" | grep -i access-control