Générateur de politique CORS
Construisez une politique CORS sécurisée et copiez la config prête pour Nginx, Apache, Express, FastAPI, Django et dix stacks de plus, avec une revue de sécurité en direct.
Ce générateur de politique CORS écrit les headers Cross-Origin Resource Sharing dont vous avez besoin plus la config qui va avec pour ce que vous faites vraiment tourner, le tout dans votre navigateur, donc vos origins ne quittent jamais la page. Vous indiquez quelles origins vous validez, quelles méthodes vous autorisez, si les requêtes transportent des cookies, et un Max-Age, puis nous renvoyons les headers bruts et les snippets prêts pour Nginx, Apache, Express, Node, FastAPI, Flask, Django, ASP.NET Core, Spring, Caddy, Traefik, HAProxy, IIS et Cloudflare Workers. Vous pouvez partir d'un preset pour une API publique en lecture seule, une SPA avec credentials, une API à jeton ou une politique verrouillée. Une revue de sécurité en direct nomme les combinaisons dangereuses en clair, le cas du wildcard avec credentials avant tout, avant le déploiement. Il aide les équipes backend et DevOps à publier une politique correcte du premier coup.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
Générateur de politique CORS, headers + 14 configs serveurs et frameworks
Ce générateur de politique CORS construit les response headers dont votre API a besoin plus la config serveur qui va avec, le tout dans votre navigateur. Vous indiquez quelles origins vous validez, quelles méthodes vous autorisez et si les requêtes transportent des cookies, et nous renvoyons la config pour ce que vous faites vraiment tourner : Nginx, Apache, Express, FastAPI, Flask, Django, ASP.NET Core, Spring, Caddy, Traefik, HAProxy, IIS et Cloudflare Workers, quatorze stacks en tout, plus les headers bruts. Vous pouvez partir d'un preset pour une API publique, une SPA avec credentials ou une configuration verrouillée. Une revue de sécurité en direct suit chaque changement et nomme les combinaisons dangereuses en clair, le cas du wildcard avec credentials avant tout, avant le déploiement. Tout tourne dans votre navigateur, rien de ce que vous saisissez n'est envoye.
https://app.example.com X-Request-Id, X-RateLimit-Remaining Comment fonctionne ce générateur CORS
Voici le modèle mental qui m'a enfin fait comprendre CORS. C'est une poignée de response headers qui disent au navigateur quels autres sites ont le droit de lire ce que ton serveur renvoie. C'est le navigateur qui applique. Ton serveur, lui, se contente de déclarer les règles en espérant ne pas s'être trompé. Donc tu choisis un preset, ou tu règles tes origins et tes méthodes à la main, tu indiques si les requêtes transportent des cookies, et il te sort les headers exacts plus la config pour quatorze stacks courantes. Ça se met à jour pendant que tu tapes. Et la revue de sécurité te signale tout ce qui sent mauvais, en clair, avant que tu déploies.
Les response headers CORS expliqués
| Header | Ce qu'il fait |
|---|---|
Access-Control-Allow-Origin | L'unique origin autorisée à lire la réponse, ou * pour n'importe laquelle. Avec credentials, il faut une origin exacte, jamais *. |
Access-Control-Allow-Methods | Les méthodes HTTP permises dans la vraie requête, renvoyées sur le preflight. |
Access-Control-Allow-Headers | Les request headers que le client peut envoyer (par exemple Authorization, Content-Type). |
Access-Control-Allow-Credentials | À mettre sur true pour autoriser les cookies et le header Authorization. Force une origin exacte. |
Access-Control-Expose-Headers | Les response headers que JavaScript a le droit de lire au-delà de la safelist par défaut. |
Access-Control-Max-Age | Combien de temps (en secondes) le navigateur met en cache le résultat du preflight. Les navigateurs le plafonnent (Chromium 7200, Firefox 86400). |
Vary: Origin | Indispensable quand tu reflètes l'origin, pour que les caches ne servent pas la réponse d'une origin à une autre. |
Le piège du wildcard avec credentials
L'erreur CORS sur laquelle je tombe le plus souvent ? Activer les credentials tout en reflétant n'importe quelle origin. La spec ne te laisse pas combiner Access-Control-Allow-Origin: * avec Access-Control-Allow-Credentials: true, alors les gens font les malins et renvoient en écho l'Origin que le navigateur a envoyée. S'il te plaît, ne fais pas ça. Ça donne à tous les sites de la planète le pouvoir de faire des appels authentifiés avec les cookies de ton utilisateur et de lire la réponse. Tu viens de couper la protection cross-origin en douce, tout en laissant le feu vert allumé. Tu as vraiment besoin des credentials ? Vérifie l'origin entrante contre une vraie allowlist. Et c'est exactement ce que tu obtiens ici dès que tu listes des origins précises au lieu du wildcard.
Les requêtes preflight
Tout ce qui n'est pas une requête « simple » pousse le navigateur à envoyer d'abord un preflight OPTIONS pour demander la permission. Un header custom suffit. Un body JSON aussi, ou n'importe quelle méthode au-delà de GET, POST ou HEAD. Ton serveur doit répondre à ce preflight avec les headers CORS et un 2xx avant que la vraie requête passe. Oublie ça et tout casse, en général sans un mot, ce qui te promet un après-midi sympa. Les configs Nginx, Node, Caddy et HAProxy d'ici intègrent déjà le petit court-circuit qui répond à OPTIONS par un 204. Une chose de moins à retenir.
Questions fréquentes
Pourquoi ma politique CORS ne marche pas alors que j'ai bien posé le header ?
D'expérience, c'est presque toujours l'une de ces quelques causes. Le preflight OPTIONS n'obtient jamais de 2xx portant les headers. Ou tu as combiné Access-Control-Allow-Origin: * avec les credentials, ce que le navigateur refuse net. Peut-être qu'un proxy ou un CDN supprime discrètement les headers en sortie, celle-là est sournoise. Ouvre l'onglet des headers bruts pour voir ce qui devrait partir. Puis compare avec la vraie réponse dans le network panel de ton navigateur. L'écart saute en général aux yeux dès que tu regardes pour de vrai.
Puis-je utiliser une origin en wildcard avec des cookies ou Authorization ?
Non. Et tu ne pourras pas non plus la faire passer en douce devant le navigateur. Dès que Access-Control-Allow-Credentials passe à true, le wildcard est rejeté pour l'origin (et pour Allow-Headers et Expose-Headers, tant qu'on y est). Tu dois renvoyer l'origin exacte qui a demandé, vérifiée contre une allowlist, plus Vary: Origin. Liste tes origins précises, coche credentials, et l'outil te câble tout ça.
C'est quoi une requête preflight et quand se déclenche-t-elle ?
C'est la requête OPTIONS automatique que le navigateur envoie avant un appel cross-origin non simple. En gros, elle demande si elle a le droit de faire ça. Tu la déclenches avec n'importe quelle méthode au-delà de GET, POST ou HEAD. Un Content-Type comme application/json la déclenche aussi, ou n'importe quels request headers custom. Ton serveur répond avec les Allow-Methods et les Allow-Headers et un 2xx. Et là, la vraie requête part.
Est-ce que CORS protège mon serveur ?
Non. Celle-là, elle piège pas mal de monde. CORS vit dans le navigateur, et il protège tes utilisateurs, pas ton serveur. Tout ce qu'il contrôle, c'est de savoir si le JavaScript d'un autre site peut lire tes réponses. Ce n'est pas de l'auth. Ce n'est pas un firewall. N'importe qui peut toujours taper ton API direct depuis curl et tout récupérer. Postman aussi. Garde ta vraie autorisation et ton rate limiting sur le serveur, là où ils servent vraiment à quelque chose.