Sécuriser une application générée par IA : la check-list Supabase, clés et fonctions

Pourquoi une application générée par IA est souvent exposée

Les générateurs d'applications produisent vite une interface qui marche. Leur objectif est que l'écran affiche les bonnes données, et le moyen le plus court consiste souvent à ouvrir largement l'accès à la base. Tant que l'application reste une maquette, le risque est faible. Dès que de vrais clients y saisissent leurs données, il devient sérieux.

Le point commun de ces applications : le navigateur parle directement à la base de données, souvent Supabase. La sécurité repose alors entièrement sur les règles écrites dans la base. Si ces règles manquent, toute personne qui ouvre les outils de développement de son navigateur peut lire, modifier ou supprimer des données.

Supabase : activer et tester les règles RLS

La clé publique de Supabase, dite clé anon, est conçue pour être visible dans l'application. Elle ne protège rien à elle seule. La protection vient de la Row Level Security (RLS), qui filtre chaque ligne selon l'utilisateur.

Les contrôles à faire

• RLS activée sur chaque table du schéma public, sans exception.
• Une politique par opération : lecture, création, modification, suppression. Une politique qui autorise tout à tout le monde annule la protection.
• Des conditions liées à l'utilisateur : un client ne voit que ses commandes, un praticien que ses patients, un administrateur ce que son rôle permet.
• Les vues : une vue peut contourner les règles des tables qu'elle lit si elle n'est pas configurée pour les respecter.

Les clés secrètes restent côté serveur

Certaines clés donnent un accès total : la clé service_role de Supabase, la clé secrète Stripe, les clés des services d'IA, les accès aux services d'envoi d'emails. Elles ne doivent jamais figurer dans le code qui part vers le navigateur ou dans l'application mobile.

• Les variables d'environnement préfixées pour le navigateur, comme NEXT_PUBLIC_ ou VITE_, sont publiques par construction. N'y mettez jamais une clé secrète.
• Les appels qui exigent une clé secrète passent par une fonction serveur : route d'API, fonction Edge, serveur dédié.
• Une clé qui a déjà été publiée doit être révoquée et remplacée. La retirer du code ne suffit pas, l'historique du dépôt la conserve.
• Les clés d'IA reçoivent un plafond de dépense pour limiter les dégâts en cas de fuite.

Les fonctions Postgres ouvertes au rôle anon par défaut

C'est le piège le moins connu. Dans PostgreSQL, une fonction nouvellement créée est exécutable par tout le monde par défaut. Dans Supabase, cela inclut le rôle anon, c'est-à-dire un visiteur non connecté, qui peut l'appeler directement par l'API.

Le risque est maximal pour les fonctions déclarées security definer : elles s'exécutent avec les droits de leur créateur et ignorent donc les règles RLS. Une fonction de ce type ouverte à anon peut exposer toute une table.

Les corrections

• Retirez le droit d'exécution à public et à anon, puis accordez-le uniquement aux rôles qui en ont besoin.
• Vérifiez dans la fonction que l'utilisateur a le droit d'agir sur les données demandées.
• Fixez explicitement le chemin de recherche des schémas dans les fonctions security definer.

Stockage, authentification et paiements

• Stockage des fichiers : un bucket public est lisible par toute personne qui connaît l'adresse du fichier. Les documents des clients vont dans un bucket privé, avec des liens temporaires.
• Authentification : confirmation de l'adresse email, mots de passe robustes, limitation des tentatives, double authentification pour les comptes d'administration.
• Rôles : le rôle d'un utilisateur se décide côté serveur. Une application qui lit le rôle depuis une donnée modifiable par l'utilisateur est contournable.
• Paiements : le montant se calcule côté serveur, et chaque webhook Stripe est vérifié par sa signature avant d'être traité.
• Suppression de compte : obligatoire pour publier une application sur l'App Store, et utile pour le RGPD.

Tester avant la mise en ligne

Une règle non testée est une règle supposée. Chaque contrôle doit être vérifié avec trois profils : un visiteur non connecté, un utilisateur ordinaire qui tente d'accéder aux données d'un autre, et un administrateur.

Chez Ascendia, ces tests font partie de chaque projet. Sur la plateforme B2B d'une centrale d'achat dentaire, les phases en ligne comptent 43 tests de sécurité des données, 25 tests de calcul de coût et 38 parcours testés dans le navigateur. Sur BATECO, 209 contrôles automatisés sont passés dans le navigateur sur le site en ligne, sur mobile et sur ordinateur.

Quand l'application existe déjà, l'audit vient en premier. L'application Style224 a ainsi été reprise avec 8 failles critiques corrigées avant sa publication sur l'App Store. La démarche complète est décrite dans notre article pour reprendre une application existante.

Faire auditer son application générée par IA

Un générateur d'IA est un bon point de départ pour valider une idée. Avant d'y faire entrer de vrais clients, faites relire la base de données, les clés, les fonctions et le stockage par un développeur. L'audit liste les failles par gravité et propose les corrections, ou une reprise sur une base de logiciel sur mesure si la structure ne tient pas.

Ascendia audite et sécurise les applications web et mobiles, dont celles construites avec Lovable, Bolt ou d'autres générateurs. Le travail est sur devis, et la maintenance qui suit va de 50 € à 300 € par mois. Pour un projet mobile, consultez notre page de création d'application mobile.

Votre application générée par IA va accueillir de vrais utilisateurs ? Demandez votre audit gratuit : nous vérifions les règles d'accès, les clés et les fonctions exposées avant votre mise en ligne.