Pourquoi votre base de données laisse voir les données de tous

Si votre base de données n'a pas de règles d'accès, elle répond à toute demande qu'on lui adresse, sans demander qui est là. N'importe quel utilisateur, parfois n'importe quel visiteur, peut alors lire ou modifier des lignes qui ne sont pas les siennes. Les règles d'accès, souvent appelées Row Level Security (sécurité au niveau de la ligne), servent à dire : « chacun ne voit que ses propres lignes ».

Une base de données, c'est un classeur

Une base de données est un grand classeur. Chaque tableau (les clients, les commandes, les messages) est un tiroir, et chaque ligne est une fiche : une commande, un client, un message.

Dans beaucoup d'applications créées avec des outils d'IA, l'application s'adresse directement à la base depuis le navigateur de l'utilisateur, sans serveur intermédiaire pour filtrer. L'application demande « donne-moi mes commandes », mais rien ne garantit que la base ne répondrait pas aussi à « donne-moi toutes les commandes ».

C'est comme un classeur dont les tiroirs ne seraient pas fermés à clé : il suffit de demander, ou de s'y servir, pour tout lire. Le formulaire de l'écran ne montre que vos fiches, mais le tiroir, lui, est ouvert.

Ce que font les règles d'accès

Les règles d'accès sont posées sur la base elle-même, ligne par ligne. Elles posent des questions du genre :

• cette ligne appartient-elle à la personne qui la demande ?
• cette personne a-t-elle le droit de la lire, de la modifier, de la supprimer ?
• cette personne est-elle administratrice ?

Avec de telles règles, même si quelqu'un contourne l'écran de l'application et s'adresse directement à la base, celle-ci refuse de lui montrer ce qui n'est pas à lui. C'est une fonction standard de certains systèmes de bases de données : elle existe pour que la protection ne dépende pas de l'écran.

Pourquoi c'est si souvent mal réglé

• Les règles sont désactivées, parce que sans elles tout fonctionne immédiatement. C'est la situation la plus courante dans un prototype.
• Les règles existent mais sont trop larges : « tout utilisateur connecté peut tout lire », ce qui revient à dire que chaque client voit les autres.
• Une règle a été ajoutée pour corriger un bug, puis jamais refermée.
• L'écran est correct, donc personne ne soupçonne que la base le soit moins.

Dans tous ces cas, l'application « marche » et passe tous les tests faits à la main.

Comment tester sans être développeur

1. Créez deux comptes (A et B) et ajoutez une donnée dans chacun.
2. Connecté en A, regardez si une adresse, un identifiant ou un export permet de voir la donnée de B. Changer un numéro dans une adresse suffit souvent à tester.
3. Déconnecté, essayez d'ouvrir des pages ou des listes qui devraient exiger un compte.
4. Demandez à la personne qui a construit l'application si les règles d'accès sont activées sur chaque tableau, et ce que dit chacune.

Si l'un de ces essais échoue, ne le traitez pas comme un détail : les données de vos utilisateurs sont lisibles.

Ce que ça change pour vous

Une fuite de données de ce type n'exige aucune compétence d'attaque : une simple requête suffit. Ses conséquences sont sérieuses : perte de confiance, obligations légales vis-à-vis de vos utilisateurs, et parfois de lourdes suites. Mieux vaut le découvrir avant qu'un inconnu ne s'en charge.

Cette faille est la première du catalogue des failles typiques d'une application générée par IA, et un point de la checklist de mise en ligne.

À retenir

Une base de données sans règles d'accès répond à tout le monde : c'est à la base, et pas seulement à l'écran, de dire qui voit quelle ligne.

Et pour votre produit ?

Un audit regarde notamment ce que chaque type d'utilisateur peut lire, écrire ou supprimer, et vous remet un rapport classé par gravité. Si vous voulez savoir si vos données sont bien cloisonnées, nous pouvons en discuter lors d'un échange de 30 minutes.