Pourquoi CORS ne pose pas de problème avec Postman mais bloque dans le navigateur ?

CORS est une restriction imposée par les navigateurs web, pas par le protocole HTTP. Postman, curl et les appels serveur-à-serveur ne sont pas soumis à CORS car ils n'exécutent pas de JavaScript dans un contexte de page web. C'est uniquement le code JavaScript exécuté dans un navigateur qui est contraint par la politique CORS.

Puis-je utiliser Access-Control-Allow-Origin: * en production ?

C'est possible pour les API publiques qui n'utilisent pas de cookies ni d'authentification par session. Pour les API privées qui envoient des credentials (cookies, tokens dans les en-têtes), vous devez spécifier les origines exactes. Le wildcard * est incompatible avec Access-Control-Allow-Credentials: true.

Comment autoriser plusieurs origines ?

L'en-tête Access-Control-Allow-Origin n'accepte qu'une seule valeur (ou *). Pour autoriser plusieurs domaines, le serveur doit vérifier dynamiquement l'en-tête Origin de la requête et le renvoyer si l'origine est autorisée. Tous les frameworks listés dans notre configurateur gèrent automatiquement ce comportement quand vous fournissez une liste d'origines.

Testeur et configurateur CORS en ligne - En-têtes et configuration

Testeur CORS

Configurez vos en-têtes CORS (Cross-Origin Resource Sharing) visuellement et générez la configuration pour votre framework : Express.js, Fastify, Django, Flask, Spring Boot, Nginx ou Apache. Sélectionnez les origines autorisées, les méthodes HTTP, les en-têtes, activez les credentials et le preflight. Obtenez les en-têtes HTTP bruts et le code de configuration prêt à copier.

const cors = require('cors'); app.use(cors({ origin: "https://example.com", methods: ['GET', 'POST', 'PUT', 'DELETE'], allowedHeaders: ['Content-Type', 'Authorization'], credentials: false, maxAge: 86400 }));

Qu'est-ce que CORS et pourquoi est-ce nécessaire ?

CORS (Cross-Origin Resource Sharing) est un mécanisme de sécurité des navigateurs qui bloque par défaut les requêtes HTTP entre domaines différents. Si votre frontend sur app.example.com appelle une API sur api.example.com, le navigateur bloque la requête sauf si le serveur API envoie les bons en-têtes CORS. C'est une protection contre les attaques CSRF, mais elle cause souvent des erreurs frustrantes en développement ("has been blocked by CORS policy").

Comment fonctionnent les requêtes preflight ?

Pour les requêtes "complexes" (PUT, DELETE, ou avec des en-têtes personnalisés), le navigateur envoie d'abord une requête OPTIONS (preflight) pour demander au serveur s'il autorise la requête réelle. Le serveur doit répondre avec les en-têtes Access-Control-Allow-Origin, Access-Control-Allow-Methods et Access-Control-Allow-Headers. Le header Access-Control-Max-Age indique combien de temps le navigateur peut mettre en cache la réponse preflight pour éviter de la répéter à chaque requête.

Erreurs CORS courantes et solutions

L'erreur la plus fréquente est l'absence de l'en-tête Access-Control-Allow-Origin dans la réponse du serveur. Autres pièges courants : utiliser Access-Control-Allow-Origin: * avec Access-Control-Allow-Credentials: true (interdit par les navigateurs), oublier de gérer la méthode OPTIONS pour les preflight, ne pas inclure les en-têtes personnalisés dans Access-Control-Allow-Headers, et configurer CORS côté frontend au lieu du backend (c'est le serveur qui doit envoyer les en-têtes, pas le client).

Testeur CORS

En-têtes HTTP CORS

Configuration Express.js (Node)

Qu'est-ce que CORS et pourquoi est-ce nécessaire ?

Comment fonctionnent les requêtes preflight ?

Erreurs CORS courantes et solutions

Questions fréquentes

Outils similaires

Formater du JSON

Minifier du CSS / JS

Testeur de regex

Générateur d'UUID

Encoder / Décoder URL

Convertir JSON en CSV