Dans le cadre de la série Security Masterclass d'Aikido, Mackenzie Jackson s'est entretenu avec Bill Harmer (CISO, Supabase) et Etienne Stalmans (Security Engineer, Supabase) pour explorer comment Supabase aborde la sécurité dès la conception, et non comme un ajout ultérieur.
De la sécurité au niveau des lignes (RLS) aux risques du codage assisté par l'IA, la discussion a porté sur ce qu'il faut pour construire rapidement et rester sécurisé.
La sécurité commence par les données
La philosophie de Supabase commence avec les données elles-mêmes.
« Nous avons construit Supabase du point de vue d'un développeur. Tout commence avec les données. Pourquoi construire des couches secondaires quand on peut tout contrôler en un seul endroit. » - Bill Harmer, CISO Supabase
Au lieu de disperser la logique de sécurité entre les services, Supabase la rapproche de l'endroit où résident les données. Plus le contrôle est proche, moins il y a de chances que les choses tournent mal.
Construire à partir des premiers principes
Pour Etienne, cette approche modifie la façon dont les développeurs conçoivent la création de logiciels.
« Lorsque vous rapprochez la sécurité de vos données, vous commencez à y penser à partir des premiers principes. Une fois que cela fait tilt, vous accélérez le développement et restez confiant quant à sa sécurité. » - Etienne Stalmans, Ingénieur Sécurité Supabase
En intégrant la propriété et l'accès aux données dans la conception des applications, les équipes éliminent les incertitudes liées aux systèmes de permissions multicouches.
Anonyme ou authentifié
Supabase simplifie le contrôle d'accès. Les utilisateurs sont soit anonymes, soit authentifiés, rien entre les deux.
« Toutes les mises à jour de données doivent être journalisées : qui a fait quoi, quand et pourquoi. Les utilisateurs anonymes ont un accès limité. Les utilisateurs authentifiés obtiennent exactement ce dont ils ont besoin et rien de plus. » - Bill Harmer, CISO Supabase
Etienne a démontré cela pendant la session en utilisant une application de partage de recettes en direct.
Les recettes publiques étaient visibles par tous. Les recettes privées n'étaient visibles que par leurs propriétaires ou des utilisateurs partagés spécifiques.
Quelques lignes de SQL, soutenues par la sécurité au niveau des lignes (Row Level Security), géraient l'ensemble du modèle.
La sécurité au niveau des lignes (Row Level Security) est non négociable
Le RLS définit qui peut voir ou modifier quelles lignes de données. C'est l'une des fonctionnalités les plus puissantes de Postgres et l'une des plus faciles à négliger.
« C'est tout ce qu'il faut, une vérification manquante et tout est exposé. » - Etienne Stalmans, Ingénieur Sécurité Supabase
Etienne a partagé un exemple où une politique générée par IA a accidentellement renvoyé chaque enregistrement d'une table parce qu'elle avait ignoré une condition.
La correction a été une simple modification de la requête, une ligne qui a comblé une faille de sécurité majeure.
Bill l'a résumé simplement :
« Nous voulons que la sécurité soit aussi proche des données que possible. Plus elle est proche, moins il y a de place pour l'erreur. » - Bill Harmer, CISO Supabase
Tester vos politiques avec pgTAP
La sécurité ne s'arrête pas une fois l'application déployée. Etienne a montré comment Supabase utilise pgTAP pour tester continuellement les politiques de base de données.
« Vous pouvez prouver que ce que vous croyez sécurisé l'est réellement. Ces tests vous maintiennent honnête. » - Etienne Stalmans, Ingénieur Sécurité Supabase
Chaque test vérifie ce qui compte le plus :
- Les utilisateurs publics ne voient que les données publiques
- Les utilisateurs authentifiés ne voient que ce qui leur appartient.
- Les politiques appliquent systématiquement les limites attendues.
Cette assurance continue garantit que les petites erreurs ne se transforment pas en fuites de données.
Sécurité évolutive
Supabase exécute le RLS pour des millions d'utilisateurs et des charges de travail importantes sans problème.
« Nous l'utilisons partout, même à grande échelle. Aucun problème, aucune excuse. » - Etienne Stalmans, Ingénieur en sécurité Supabase
En appliquant la sécurité au niveau de la base de données, Supabase maintient la logique cohérente, quelle que soit la complexité de l'application.
« Faites-le simplement fonctionner », l'invite dangereuse
Bill a clôturé la session avec un avertissement pour quiconque utilisant l'IA pour générer du code.
« Ce n'est pas parce que ça fonctionne que c'est prêt pour la production. » - Bill Harmer, CISO Supabase
« Si vous demandez à une IA de faire fonctionner quelque chose, elle pourrait supprimer les contrôles de sécurité mêmes qui vous protègent. » - Bill Harmer, CISO Supabase
Les modèles d'IA ne comprennent pas l'intention. Ils feront tout ce qu'il faut pour atteindre l'objectif que vous avez fixé, même si cela signifie désactiver le RLS ou supprimer la logique d'authentification.
Le danger n'est pas d'utiliser l'IA, c'est de l'utiliser sans encadrement.
« Le modèle n'est pas malveillant. Il fait son travail. Mais il ne connaît pas votre intention. C'est votre travail. » - Bill Harmer, CISO Supabase
Développer de manière sécurisée par défaut
La sécurité n'est pas un obstacle. C'est ainsi que vous avancez plus vite sans remettre en question ce que vous livrez.
Supabase prouve que lorsque la sécurité réside au niveau de la couche de données, elle fait partie intégrante de votre façon de construire, et non une réflexion après coup.
