Dans une application Symfony multi-tenant, un rôle PostgreSQL ne possédant aucune table peut néanmoins contourner les politiques Row-Level Security (RLS) s’il hérite des privilèges du propriétaire. L’auteur montre pourquoi un contrôle fondé sur current_user et session_user passe à côté de cette faille et recommande pg_has_role pour inspecter les appartenances. Il détaille une configuration à trois rôles avec GRANT ... WITH INHERIT FALSE, SET TRUE, puis souligne un piège de Doctrine DBAL : SET LOCAL ROLE et le contexte du tenant doivent être appliqués dans une transaction englobant les lectures.

L’article explique comment la sécurité au niveau des lignes (RLS) dans PostgreSQL peut être contournée dans un projet Symfony en raison du rôle propriétaire des tables. Bien que les politiques RLS soient activées, le rôle qui exécute les migrations (et donc possède les tables) ignore ces restrictions par défaut, exposant toutes les données sans restriction. Un simple ALTER TABLE ... FORCE ROW LEVEL SECURITY est nécessaire pour appliquer correctement les politiques.

L’auteur souligne que cette faille est difficile à détecter en tests, car les connexions de test utilisent souvent un superutilisateur qui contourne aussi la RLS. La configuration par défaut de Symfony, où le même rôle gère à la fois les migrations et l’application, crée un risque de fuite de données. La documentation PostgreSQL mentionne ce comportement, mais il est souvent ignoré lors de la mise en place des politiques.