Row-Level Security : mettez la sécurité dans la base, pas dans le code

Voici un scénario que tout développeur a vu : une API qui renvoie les données d'un utilisateur, avec une condition « where user_id = ? » dans le code. Ça marche — jusqu'à ce qu'une nouvelle route oublie la condition, ou qu'un stagiaire copie-colle une requête sans le filtre. D'un coup, n'importe qui peut lire les données de n'importe qui.

Le problème : la sécurité vit au mauvais endroit

Quand la règle « chaque utilisateur ne voit que ses données » n'existe que dans le code de l'application, elle doit être répétée à chaque requête, dans chaque route, par chaque développeur, pour toujours. Une seule omission et c'est la fuite. Le code d'application est le pire endroit pour une garantie de sécurité : il change tout le temps, et il est écrit par des humains pressés.

La solution : Row-Level Security (RLS)

PostgreSQL permet d'attacher des politiques de sécurité directement aux tables. Une politique RLS est une règle que la base applique à chaque requête, quelle que soit l'origine. Exemple : « un utilisateur ne peut lire une ligne que si son identifiant correspond à la colonne user_id ». Une fois posée, cette règle est impossible à oublier — elle vit dans la table, pas dans le code.

Concrètement : activez RLS sur la table, écrivez une politique une fois, et toutes vos requêtes — API REST, code serveur, requêtes manuelles — la respectent automatiquement. Le développeur ne peut plus se tromper, parce qu'il n'a plus rien à se rappeler.

Sécurisé par défaut

Le bon réflexe : activer RLS dès la création d'une table, avant d'y mettre la moindre donnée. Sans politique, la table est fermée — personne ne lit rien tant que vous n'avez pas explicitement autorisé quelque chose. C'est l'inverse du réflexe habituel (« tout est ouvert, je restreindrai plus tard »), et c'est précisément pour ça que c'est sûr.

Chez MedBase, c'est le défaut

Quand vous créez une table dans MedBase, la sécurité au niveau des lignes est activée automatiquement. Vous choisissez à ce moment-là : privée (accessible seulement avec votre clé serveur) ou en lecture publique (une politique de lecture est posée pour vous). Pas de case à cocher oubliée, pas de fuite par défaut. La sécurité vit dans la base, exactement là où elle devrait être.