Posture de sécurité

Définition

Toutes les tables publiques ont la RLS activée avec des politiques scopées à auth.uid() et des helpers (can_manage_ride, has_role, is_super_admin). Les champs sensibles (téléphone d'activité, code de réservation, infos internes d'hôtel) sont exclus des vues sûres côté motard (hotels_safe, activities_safe, day_restaurants_safe). Le bucket ride-photos est privé et son accès est régi par politique.

Quand l'utiliser

À chaque ajout de table, colonne, bucket, ou changement de politique.

Étapes

1. Lancez le scan de sécurité (panneau Sécurité → Scanner).
2. Examinez les résultats ; corrigez ou ignorez via le panneau du scanner.
3. Pour une nouvelle table : activez la RLS dans la MÊME migration, GRANT aux bons rôles, ajoutez des politiques scopées utilisateur.
4. Pour une nouvelle colonne sensible : étendez la *_safe correspondante pour l'exclure, et routez les requêtes motard via la vue sûre.

Capture d'écran

Capture à venir dans la prochaine passe.

Astuces

• Mettez à jour le mémo sécurité en ignorant des findings, pour qu'ils ne ré-apparaissent pas.
• Ne stockez jamais les rôles sur la table profil — toujours dans user_roles.
• Lancez le scan de sécurité intégré après tout changement de schéma ; il signale RLS manquante, GRANT manquant, politiques trop permissives.
• À chaque nouvelle table en migration, incluez GRANTs et RLS dans la même migration — une migration partielle laisse une faille.

Dépannage

• « permission denied for table » : GRANT manquants sur la nouvelle table — voir la règle public-schema-grants de Lovable.
• « Permission refusée » sur une requête légitime : un GRANT manque pour le rôle de l'utilisateur. Le hint Postgres nomme généralement le GRANT à exécuter.