Un joker CORS est-il un risque de sécurité ? Rarement.

Votre scan est revenu avec une ligne qui se lit comme une alarme : votre API est ouverte à n'importe quel site. Ou bien quelqu'un de technique a regardé ce que renvoie votre serveur et vous a dit que votre application a un joker CORS, c'est-à-dire le caractère *, ce qui apparemment veut dire tout le monde.

Voici la partie que guide après guide présente de travers : le joker n'est presque jamais ce qui a ouvert votre API. C'est une instruction que votre serveur attache à ses réponses, adressée aux navigateurs de gens installés sur d'autres sites, et elle arrive après que la réponse est déjà partie. Le restreindre empêche la page d'un autre site de lire vos données. Cela ne change rien pour quiconque les lit sans navigateur du tout.

Un joker CORS est-il un risque de sécurité ?

En lui-même, presque jamais. Il en devient un dès l'instant où quelque chose de privé répond derrière lui.

Le joker est la valeur * dans un en-tête de réponse appelé Access-Control-Allow-Origin, et il signifie que le code de n'importe quel site peut lire cette réponse-là. Cela ressemble à une déclaration sur qui peut atteindre vos données. C'est une déclaration sur qui peut lire ce que votre serveur a déjà envoyé.

L'adresse que vérifie un scan est celle depuis laquelle votre application est servie. Chez la plupart des builders, cette adresse distribue vos pages, vos images et votre code compilé, et tout cela part vers chaque visiteur par conception. Un joker là-dessus accorde la permission de lire des fichiers que n'importe qui pouvait déjà télécharger en ouvrant votre site.

Le constat est donc une question et non un verdict, et la question est de savoir ce qui se trouve derrière l'en-tête. Si la réponse est votre page d'accueil, il ne s'est rien passé. Si la réponse est une liste de vos clients, cette liste était déjà accessible à quiconque détenait l'adresse.

Ce que fait réellement Access-Control-Allow-Origin

Il dit au navigateur de votre visiteur si la page affichée a le droit de regarder une réponse que votre serveur a déjà envoyée.

L'ordre des choses est l'essentiel, et il va à rebours de ce que presque tout le monde imagine. Une page sur un autre site exécute un morceau de code qui demande des données à votre application. La requête part. Votre serveur la reçoit, exécute ce qu'il a à exécuter et renvoie la réponse en entier. Ce n'est qu'ensuite que le navigateur lit l'en-tête de cette réponse et décide s'il remet le contenu à la page qui l'a demandé. Le guide CORS de MDN le résume en une ligne : le serveur doit donner son accord avec Access-Control-Allow-Origin pour partager la réponse avec le script.

Vos données ont quitté le bâtiment dans les deux cas. Ce que l'en-tête décide, c'est si un morceau de code précis, tournant dans le navigateur d'une personne précise, arrive à les voir.

Le navigateur est la seule chose dans cette histoire qui lise l'en-tête. Un script sur un serveur, un outil en ligne de commande, un scraper, une application mobile : aucun ne le consulte, car il a été écrit pour un navigateur et aucun navigateur n'entre en jeu. Ils envoient la même requête, reçoivent la même réponse et en lisent chaque octet.

Restreindre CORS ne rend pas privé un endpoint ouvert

Parce que CORS vit à l'intérieur des navigateurs, et que celui qui se sert dans vos données n'a aucune raison d'en utiliser un.

C'est la partie qui coûte un après-midi. On voit le constat du joker, on resserre l'en-tête sur son propre domaine, on redéploie, on rescanne, et l'adresse qui distribuait des lignes de clients distribue toujours des lignes de clients. Elle l'a toujours fait. Le seul appelant qui se soit jamais arrêté, c'était la page web de quelqu'un d'autre.

Lisez deux fois la dernière ligne, car c'est là que le conseil générique s'effondre. Un simple joker ne peut pas servir à lire des données appartenant à votre visiteur connecté. Les navigateurs refusent cette combinaison sans discuter, et le guide CORS de MDN le dit directement : si une requête porte un cookie et que la réponse revient avec Access-Control-Allow-Origin: *, le navigateur bloque l'accès à la réponse et signale une erreur CORS dans la console. C'est donc le joker, précisément, qui rend cette attaque-là impossible.

La colonne qui livre bel et bien les données d'un utilisateur connecté est la troisième, et il faut pour cela que le serveur inscrive l'adresse de l'appelant lui-même dans sa réponse.

Le réglage CORS qui est vraiment dangereux

Un serveur qui lit l'en-tête Origin de la requête, écrit cette même valeur dans sa propre réponse et envoie Access-Control-Allow-Credentials: true avec elle.

Personne ne décide de faire ça. Cela arrive au bout d'un après-midi passé à essayer de faire marcher un joker avec des requêtes authentifiées, et à découvrir qu'il ne marchera jamais. Renvoyer en écho l'origine qui a demandé ressemble à la solution : tout site qui devrait être autorisé l'est, les erreurs de console cessent, la fonctionnalité part en production. Ce que le serveur dit en réalité, c'est que l'appelant décide, ce qui inclut une page que personne n'a encore écrite.

Voici ce que cela permet. Votre cliente est connectée à votre application, avec un cookie de session dans son navigateur. Dans un autre onglet, elle ouvre un site qui n'a rien à voir avec vous. Le code de ce site demande son compte à votre API. Son navigateur joint le cookie, parce que joindre des cookies est ce que font les navigateurs. Votre serveur lit une Origin dont il n'a jamais entendu parler, la tamponne dans la réponse comme permission et ajoute que les identifiants sont acceptés. Le navigateur vérifie, trouve une correspondance et remet les données de votre cliente à une page dont elle ignorait qu'elle les lisait.

Dans notre balayage d'août 2026, cela est apparu sur 61 des 30 926 applications où la vérification a pu obtenir une réponse. Des trois constats CORS, c'est le seul qui atteigne des données situées derrière une connexion.

À quelle fréquence un joker apparaît, et qui en décide

C'est surtout votre builder qui décide. Dans ce même balayage, 5 727 de ces 30 926 applications envoyaient un joker, et le meilleur indicateur pour savoir si la vôtre le fait est la plateforme qui l'a publiée.

La vérification CORS a signalé au moins un constat sur 5 418 des 5 419 applications Base44 pour lesquelles elle a obtenu une réponse, et sur 8 des 18 518 applications Lovable. Replit se situe entre les deux, avec 1 129 sur 3 037. Un écart aussi large, c'est à cela que ressemble un réglage par défaut d'hébergement vu de l'extérieur : quasi total sur une plateforme, quasi absent sur une autre, à travers des milliers d'applications dont les propriétaires n'ont jamais rien coordonné.

Trois constats distincts composent la vérification CORS sur l'ensemble des 30 926 applications : un joker sur 5 727 d'entre elles, une adresse qui répond avec des données et sans connexion sur 3 852, et la forme de l'origine renvoyée en écho sur 61. Le total dépasse la vérification elle-même, car beaucoup d'applications en cumulent deux sur trois. Chaque chiffre ici provient de notre scan de 30 998 applications vibe-codées en ligne, qui publie chacun avec la base sur laquelle il a été mesuré.

Ce sur quoi vous pouvez agir se répartit de la même façon. Le joker est envoyé par celui qui sert votre application, et pour une application vibe-codée c'est généralement le builder. Ce qui revient quand un inconnu demande des données à l'une de vos adresses a été décidé à l'intérieur de votre application, par vous ou par le builder qui écrit du code en votre nom.

Comment vérifier votre propre application

Deux choses à regarder, et la seconde est celle qui décide si tout cela compte.

Votre application envoie-t-elle un joker ? Ouvrez votre application en production, appuyez sur F12 pour faire apparaître les outils de développement du navigateur, cliquez sur Network et rechargez la page. Cliquez sur la première requête de la liste et lisez le panneau Response Headers. Une ligne indiquant access-control-allow-origin: * est le constat. Aucune ligne de ce genre signifie que votre serveur ne partage rien entre origines avec personne.

Qu'est-ce qui répond derrière ? Restez dans l'onglet Network et rechargez votre application en étant connecté, en guettant les requêtes qui reviennent en JSON. Ce sont les adresses auprès desquelles votre application récupère des données. Copiez chaque URL, ouvrez une fenêtre de navigation privée pour être déconnecté, et collez-les une par une. Tout ce qui revient avec de vraies lignes au lieu d'une erreur ou d'une liste vide est lisible par n'importe qui sur internet disposant de cette URL. C'est vrai aujourd'hui, quoi que dise votre en-tête CORS, et cela reste vrai après que vous l'avez resserré.

Notre scan gratuit fait la seconde vérification pour vous : il lit le code de votre application à la recherche des adresses qu'elle appelle, interroge chacune sans connexion et signale celles qui ont répondu avec des données. Il prend une vingtaine de secondes et ne demande aucun compte : scannez votre application.

Si votre application parle à Supabase directement depuis le navigateur, il y a un troisième endroit à regarder, car les règles posées sur chaque table décident qui peut lire quelles lignes, et les activer ne revient pas à être protégé.

Ce qu'il faut faire maintenant

L'habitude qui vaut la peine d'être gardée, c'est le passage déconnecté sur vos propres adresses de données, car chaque nouvelle fonctionnalité en ajoute une et rien ne change à l'écran quand l'une d'elles se met à répondre. Reeve Care relance ce scan contre votre application en production selon un calendrier et vous écrit quand un résultat se dégrade : ce qu'il surveille et ce qu'il coûte.

Si vous préférez tout traiter d'un seul coup, la checklist de sécurité en 10 minutes couvre ce point à côté du reste de ce qu'une application fraîchement lancée a tendance à laisser ouvert, et quelles clés sont sûres dans votre frontend est l'autre moitié de la question avec laquelle les gens arrivent en général.