Supabase RLS : les 5 erreurs qu'on retrouve dans chaque audit de SaaS RH

Le faux sentiment de sécurité

Supabase est devenu le choix par défaut de beaucoup de startups RH françaises. Et pour cause : base PostgreSQL managée, authentification intégrée, API auto-générée. On peut livrer un MVP en quelques semaines.

Le problème, c'est que cette rapidité crée un faux sentiment de sécurité. "On a activé RLS, donc c'est sécurisé." Non. Activer RLS, c'est poser un cadenas sur la porte. Mais si la policy autorise tout le monde, le cadenas ne sert à rien.

Voici les 5 erreurs qu'on retrouve systématiquement.

Erreur 1 : la policy trop permissive sur SELECT

La policy la plus courante qu'on voit :

```sql

CREATE POLICY "Users can read" ON employees

FOR SELECT USING (true);

`

Tous les utilisateurs authentifiés peuvent lire tous les employés. Dans un SaaS multi-tenant, ça signifie que l'entreprise A peut voir les salariés de l'entreprise B.

La correction :

```sql

CREATE POLICY "Users can read own org" ON employees

FOR SELECT USING (org_id = auth.jwt() ->> 'org_id');

`

Erreur 2 : oublier les policies sur les tables liées

Vous avez sécurisé la table employees, mais pas payslips. Un attaquant peut lister tous les bulletins de paie en requêtant directement la table des fiches de paie, même sans accès à la table des employés.

Chaque table qui contient des données sensibles doit avoir ses propres policies. Et les jointures doivent être vérifiées : si payslips a une colonne employee_id, la policy doit vérifier que l'employé appartient bien à l'organisation de l'utilisateur.

Erreur 3 : le service_role key dans le frontend

On le voit encore régulièrement : la clé service_role de Supabase codée en dur dans le code JavaScript frontend. Cette clé bypasse toutes les RLS policies. Quiconque inspecte le code source peut l'extraire et accéder à toute la base de données.

La clé service_role ne doit jamais quitter votre serveur. Le frontend utilise la clé anon — c'est pour ça que les RLS policies existent.

Erreur 4 : pas de policy sur INSERT et UPDATE

Beaucoup d'équipes mettent des policies sur SELECT mais oublient INSERT et UPDATE. Résultat : un utilisateur authentifié peut créer un employé dans n'importe quelle organisation, ou modifier le salaire d'un collaborateur d'une autre entreprise.

Chaque opération (SELECT, INSERT, UPDATE, DELETE) doit avoir sa propre policy. Et les policies UPDATE doivent vérifier à la fois les lignes existantes (USING) et les nouvelles valeurs (WITH CHECK).

Erreur 5 : les fonctions RPC non sécurisées

Supabase permet de créer des fonctions PostgreSQL exposées via l'API (RPC). Ces fonctions s'exécutent souvent avec les droits du créateur (SECURITY DEFINER), ce qui bypasse les RLS.

Si votre fonction RPC fait un SELECT * FROM employees WHERE id = $1 sans vérifier l'organisation, un utilisateur peut accéder à n'importe quel employé en passant l'ID directement.

Solution : utilisez SECURITY INVOKER quand c'est possible, ou ajoutez les vérifications d'organisation dans la fonction elle-même.

Comment vérifier que vos policies tiennent

Le test le plus simple : créez deux comptes utilisateurs dans deux organisations différentes. Connectez-vous avec le compte A et essayez d'accéder aux données de B. Pas seulement via l'interface — directement via l'API Supabase avec un outil comme curl ou Postman.

C'est exactement ce qu'on fait lors d'un audit Supabase chez CleanIssue. On teste chaque table, chaque endpoint RPC, chaque storage bucket. Et on documente précisément ce qui fuit et comment le corriger.