Générateur de politique CORS
Construis une politique CORS sécurisée et copie la config prête pour Nginx, Apache, Express, FastAPI, Django et 10 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 tu as besoin et la config qui va avec pour ce que tu fais vraiment tourner, le tout dans ton navigateur, donc tes origins ne quittent jamais la page. Tu lui dis quelles origins tu valides, quelles méthodes tu autorises, si les requêtes transportent des cookies, et un Max-Age, puis tu relis les headers bruts plus les snippets prêts pour Nginx, Apache, Express, Node, FastAPI, Flask, Django, ASP.NET Core, Spring, Caddy, Traefik, HAProxy, IIS et Cloudflare Workers. Pars 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 signale les combinaisons dangereuses en clair, le trou du wildcard avec credentials avant tout, avant que tu déploies.
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
CORS m'a déjà réveillé à 2 h du matin. Un déploiement part. La console vire au rouge, et plus une seule requête n'atteint l'API. Du coup, j'ai construit ça. Tu lui dis quelles origins tu valides, quelles méthodes tu autorises, si tu envoies des cookies, et il te ressort la config pour ce que tu fais vraiment tourner : Nginx, Apache, Express, FastAPI, Flask, Django, ASP.NET Core, Spring, Caddy, Traefik, HAProxy, IIS, Cloudflare Workers, quatorze stacks, plus les headers bruts. Pars d'un preset si tu veux. Et garde un oeil sur la revue de sécurité en direct. Le trou du wildcard avec credentials m'a déjà mordu, et franchement, il te mordra sûrement aussi si tu le laisses filer. Tout tourne dans ton navigateur. Je ne vois jamais tes origins, rien ne quitte la page.
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.