Cinq mille apps qui laissent fuiter des données

Ce que c'est et pourquoi ça compte

Le titre de la vidéo vient de l'actualité. Selon une analyse rapportée par Axios (mai 2026), sur environ 380 000 apps publiées avec des outils d'IA, environ 5 000 exposaient des données sensibles. Et TechCrunch (septembre 2026) : la société UpGuard a trouvé environ 16 000 bases de données sur Supabase avec des données personnelles accessibles. Quand je lis ce genre de nouvelles, une seule question m'intéresse : la mienne en fait-elle partie ? En utilisant l'app, vous ne le voyez pas, parce qu'une fois connecté, vos données arrivent comme elles doivent. Vous ne le savez qu'en testant.

Le mécanisme, en bref. Beaucoup d'apps faites avec l'IA parlent directement à la base de données, comme Supabase, depuis le navigateur ou le téléphone. Pour cela, elles emportent l'adresse du projet et une clé publique, que tout le monde peut voir. C'est normal : ce qui protège les données, ce n'est pas la clé, ce sont les règles de la base de données. Sur Supabase, elles s'appellent Row Level Security. Si elles manquent, cette clé ouvre les tables à tout le monde.

J'en ai déjà parlé dans le guide PORTA (strikt.fit/porta), avec les détails sur Supabase, Firebase et les deux clés. Voici la version à faire tout de suite : deux tests d'une minute, le prompt qui ferme et reteste, et comment lire l'avant et l'après.

Uniquement sur votre propre app

Ce test, vous le faites sur votre app et votre base de données, avec des comptes de test. Jamais sur l'app de quelqu'un d'autre, même pas pour voir si elle fait partie des cinq mille : lire des données sans autorisation peut être un délit, même si la porte est ouverte. Si vous pensez qu'une app qui n'est pas la vôtre est exposée, prévenez ceux qui la gèrent.

1. Sans connexion

Le premier test répond à une question : que voit quelqu'un qui n'a aucun compte ? Ça prend une minute.

1. Ouvrez votre app dans une fenêtre de navigation privée, sans vous connecter. Ainsi, le navigateur n'a pas votre session et vous êtes un visiteur quelconque.
2. Clic droit > Inspecter > Réseau (Network), puis rechargez la page.
3. Trouvez une requête qui va vers .supabase.co et cliquez dessus. Vous y voyez l'adresse du projet et la clé publique (publishable, ou « anon » dans les projets plus anciens). C'est normal de la voir : elle est faite pour être dans l'app.

Ouvrez ensuite un terminal et lancez cette ligne, avec seulement ces deux informations. Mettez votre projet, votre clé et le nom d'une de vos tables :

curl "https://VOTRE-PROJET.supabase.co/rest/v1/NOM_TABLE?select=*" -H "apikey: CLE_PUBLIQUE"

Essayez-la sur chaque table qui contient des données de personnes : profils, messages, commandes, e-mails. Et faites-le sur des tables qui contiennent vraiment des données, parce qu'une table vide répond [] même si elle est ouverte : vérifiez d'abord dans le tableau de bord de Supabase. Si des lignes reviennent, n'importe qui peut les lire. Si une table pleine renvoie [] ou une erreur de permission, cette table ne répond pas aux passants.

2. En tant qu'utilisateur A, les données de B

Le deuxième test est celui qu'on saute le plus souvent. La porte peut être fermée à ceux qui ne sont pas connectés et ouverte à n'importe qui une fois connecté. Encore une minute.

1. Créez deux comptes de test, A et B.
2. Avec chacun, enregistrez quelques données : un profil, une note, une commande.
3. Connectez-vous en tant que A et essayez d'ouvrir les lignes de B, par exemple en changeant l'id dans la requête ou dans l'adresse de la page.

Si vous les voyez, les règles n'existent pas. Ou elles existent mais disent « quiconque est connecté lit tout », ce qui ne suffit pas pour des données personnelles : le bon contrôle porte sur qui possède la ligne.

3. Le prompt pour Claude Code

Quand vous savez ce qui est ouvert, vous le faites fermer. Ouvrez Claude Code dans le dossier du projet et collez ceci :

Vérifie chaque table de ma base de données Supabase : dis-moi si la Row Level Security est activée et quelles règles (policies) elle a. Là où elle manque, active-la et écris les règles : chaque utilisateur lit, crée, modifie et supprime uniquement ses propres lignes ; les tables publiques par choix en lecture seule. Ne mets jamais la clé secrète (secret ou service_role) dans le code de l'app. Ensuite refais le test : sans connexion avec la clé publique, et en tant qu'utilisateur A sur les lignes de B. Montre-moi table par table le résultat avant et après.

Chaque morceau a une raison. « Lit, crée, modifie et supprime » parce que, sur Supabase, les règles s'écrivent pour chaque opération : fermer seulement la lecture laisse le reste ouvert. « Publiques par choix » parce qu'un catalogue peut être lu par tout le monde, mais ça doit être votre décision, pas un hasard. Et « refais le test » parce qu'une règle se vérifie en l'essayant, pas en la lisant.

Claude vérifie ce qu'il peut voir. Si les tables sont dans le code du projet, par exemple dans les fichiers de migration, il les trouve là. Si vous les avez créées à la main dans le tableau de bord de Supabase, dites-lui lesquelles, ou faites les deux tests à la main et donnez-lui le résultat. Et si Claude Code vous demande la permission de lancer une commande, lisez ce qu'il s'apprête à faire avant de dire oui.

Comment lire l'avant et l'après

Le résultat, vous le voulez sous une forme qui se lit d'un coup d'œil. Vous pouvez ajouter au prompt « dans un tableau comme celui-ci » et coller ce modèle :

Table | RLS avant | RLS après | Sans connexion avant | Sans connexion après | A sur B avant | A sur B après
profils | non | oui | lignes | [] | lignes | rien

À la fin, vous voulez voir trois choses : la Row Level Security activée sur chaque table, aucune ligne sans connexion sauf dans les tables publiques par choix, et A qui ne voit rien de B. Si une table ne ressort pas ainsi, demandez à Claude pourquoi avant d'aller plus loin.

Deux choses à connaître

Mieux vaut fermé qu'ouvert

Avec la Row Level Security activée et aucune règle, rien ne passe par la clé publique. Donc mieux vaut fermé qu'ouvert, puis vous n'ouvrez que ce qui est nécessaire. Si un écran ne charge plus après la correction, ne coupez pas la sécurité : il manque une règle. Faites ajouter celle-là :

L'écran [nom] ne charge plus les données depuis que tu as activé la Row Level Security. Trouve quelle règle manque et ajoute la plus stricte qui suffit. Ne désactive la sécurité sur aucune table. Ensuite refais les deux tests, sans connexion et de A vers B.

La clé secrète

La clé secrète (secret ou service_role) passe outre toutes les règles. Elle reste uniquement sur le serveur : jamais dans l'app, jamais sur GitHub. Si elle s'est retrouvée dans l'app ou dans un dépôt, changez-la tout de suite depuis le tableau de bord de Supabase. La retirer du code ne suffit pas : elle reste dans l'historique et chez ceux qui l'ont déjà vue.

Vous n'utilisez pas Supabase ?

Faites le même test avec votre plateforme : sans connexion, puis de A vers B. Les noms changent, le principe non. Sur Firebase, par exemple, les règles s'appellent règles de sécurité : ce qu'il faut chercher et le prompt pour les vérifier se trouvent dans le guide PORTA.

Les erreurs les plus courantes

• Faire le test en étant connecté. Utilisez une fenêtre de navigation privée, sinon vous voyez les données parce que c'est vous.
• Tester une seule table. Chaque table a ses propres règles : testez-les toutes, d'abord celles qui contiennent des données de personnes.
• Se fier à un [] venu d'une table vide. Une table vide répond [] même si elle est ouverte : testez-en une qui contient des données.
• S'arrêter au test sans connexion. Faites aussi celui de A vers B : c'est là que se cache la règle « quiconque est connecté lit tout ».
• Désactiver la Row Level Security quand un écran ne charge pas. Ajoutez la règle qui manque et laissez le reste fermé.
• Faire confiance à la correction sans retester. Refaites les deux tests et regardez l'avant et l'après, table par table.

Check-list

• Test sans connexion, en navigation privée, sur chaque table contenant des données de personnes.
• Test de A vers B avec deux comptes de test.
• Row Level Security activée sur chaque table, avec des règles pour lire, créer, modifier et supprimer.
• Tables publiques en lecture seule, et seulement par choix.
• Clé secrète uniquement sur le serveur, jamais dans l'app.
• Les deux tests refaits après la correction, avec l'avant et l'après sous les yeux.

Questions fréquentes