No-code ne veut pas dire no-sécurité

En 2018, la société de sécurité Appthority analyse des milliers d’applications mobiles et découvre que plus de 3 000 d’entre elles laissaient leur base de données Firebase ouverte, sans authentification. Résultat : plus de 100 millions d’enregistrements accessibles, plus de 113 Go de données, dont des mots de passe, des informations de santé et des données bancaires (source : TechTarget, Appthority, 2018).

Firebase n’était pas défaillant. Les applications non plus. Ce qui manquait tenait en une phrase : personne n’avait fermé la porte de la base.

Le malentendu du no-code

Construire vite donne un sentiment de sécurité trompeur. L’application s’affiche, les données s’enregistrent, tout marche. On en conclut qu’elle est « finie ». Mais une base de données moderne (Firebase, Supabase et les autres) est ouverte par défaut au niveau où on la configure : c’est à vous d’écrire les règles qui disent qui a le droit de lire et d’écrire quoi. Sans ces règles, la facilité de construction se paie en exposition.

Le cas Supabase : la ligne qui change tout

Beaucoup d’applications construites aujourd’hui, y compris sur Lovable, s’appuient sur Supabase. Supabase propose un mécanisme précis pour cela : le RLS (Row Level Security), la sécurité ligne par ligne. Activé et bien écrit, il garantit qu’un utilisateur ne lit que ses propres lignes. Oublié ou mal paramétré, c’est l’inverse : la table entière devient lisible par quiconque sait l’interroger.

Le piège, c’est que les deux versions, la sûre et la fuyante, se ressemblent à l’écran. L’application se comporte pareil. La différence ne se voit que si on la cherche.

Vite construit n’est pas vite sécurisé

Le no-code et le low-code ont rendu la construction accessible, et c’est une bonne nouvelle. Mais ils n’ont pas supprimé la sécurité : ils l’ont déplacée vers la configuration. Une application livrée en une semaine mérite exactement le même contrôle d’accès qu’une application développée en six mois. Le gain de temps est réel. La dispense de vérification n’existe pas.

Ce que je recommande

Si votre application stocke des données de clients, faites vérifier vos règles d’accès avant la montée en charge, pas après l’incident. L’audit regarde précisément ce point : les règles sont-elles activées, et tiennent-elles quand on les met à l’épreuve.