1 application sur 9 expose ses clés Supabase : voici comment cela arrive

Un rapport récent portant sur environ 20 000 applications indépendantes montre qu'une proportion importante d'entre elles diffuse des identifiants Supabase par erreur. Ces secrets ne sont pas extraits de serveurs piratés, mais sont directement accessibles dans le code JavaScript téléchargé par n'importe quel visiteur. L'auteur souligne que ce problème ne relève pas d'un piratage complexe, mais d'une simple erreur humaine lors du déploiement. Cette situation est critique car elle expose des infrastructures entières sans que les développeurs n'en aient conscience. Il est essentiel de comprendre que la visibilité de ces clés dans le navigateur est le point de départ de failles de sécurité majeures.

L'explication technique de cette fuite réside dans le fonctionnement des outils de build modernes comme Next.js, Vite ou SvelteKit. Ces frameworks utilisent des préfixes spécifiques tels que "NEXT_PUBLIC" pour signaler que la variable doit être injectée dans le bundle client. L'auteur rappelle avec insistance que le mot "public" sert de bon d'expédition et non d'étiquette de sécurité. Si un développeur utilise ce préfixe pour une clé privée par mégarde, l'outil l'inclura systématiquement dans le code accessible à tous. Cette confusion entre utilité de transport et niveau de sécurité est la cause racine de l'exposition des secrets.

Dans l'écosystème Supabase, il existe une distinction cruciale entre les clés anonymes publiques et les clés de service privées. L'exposition d'une clé "service_role" est particulièrement grave car elle possède le privilège de contourner les politiques de sécurité au niveau des lignes (RLS). Même si vous avez passé des heures à configurer vos règles de sécurité, une clé de service dans le front-end rend tout ce travail inutile. L'attaquant obtient alors un accès total à la base de données, ignorant toutes les restrictions mises en place. La documentation officielle est d'ailleurs très explicite sur le danger lié à l'utilisation de ces clés en dehors d'un environnement serveur sécurisé.

L'auteur illustre le problème via une application CRUD construite avec Next.js pour montrer à quel point il est facile de trouver ces informations. En inspectant simplement le bundle JavaScript compilé dans les outils de développement de Chrome, la clé privée apparaît en clair. Il insiste sur le fait qu'aucune faille complexe n'a été exploitée : l'information est littéralement offerte sur l'internet public. Cette démonstration prouve que si un développeur peut voir la clé, n'importe quel utilisateur ou bot automatisé le peut aussi. Le risque est permanent car le web est constamment scanné par des entités cherchant à exploiter ce genre d'erreurs de configuration.

Pour corriger cette faille, la recommandation principale est de faire en sorte que le navigateur n'appelle que votre propre API. Les opérations privées et l'utilisation des clés sensibles doivent impérativement être déplacées dans des routes API ou des fonctions serveur. En agissant ainsi, le client communique avec votre serveur, qui lui-même communique avec Supabase en utilisant les secrets de manière sécurisée. Après avoir effectué ce changement, il est crucial de reconstruire le projet et de vérifier manuellement que la clé a bien disparu du bundle. L'auteur suggère également de vérifier systématiquement l'activation de la RLS sur toutes les tables pour une défense en profondeur.

Pour éviter que l'erreur ne se reproduise dans l'urgence d'un déploiement futur, l'installation de garde-fous automatisés est indispensable. L'intégration de scans de secrets dans le pipeline CI/CD permet de bloquer automatiquement tout build contenant des clés suspectes. De plus, il est conseillé d'instaurer une règle stricte lors des revues de code (PR) concernant l'usage des préfixes publics. La rotation immédiate des clés est la seule réponse adéquate en cas de suspicion d'exposition pour limiter les dégâts potentiels. En conclusion, la vidéo martèle un principe fondamental : tout ce qui finit dans le bundle JavaScript doit être considéré comme une information publique.