Retour au blog
HR TechSupabaseSIRH

SIRH sur Supabase : la checklist de séparation des données

Publié le 2026-04-16 · Mis à jour le 2026-06-016 min de lectureCleanIssue

> En bref : Les vérifications à faire sur un SIRH construit sur Supabase : policies RLS, périmètre d'organisation, documents et rôles métier.

Quelles sont les failles de sécurité courantes dans une app Supabase ?

Un SIRH sur Supabase peut aller vite, mais pas sans discipline

Le vrai sujet n'est pas seulement d'activer RLS. Il faut vérifier que la séparation tient selon l'entreprise, le rôle, le périmètre manager et le cycle documentaire.

Pour aller plus loin — lire notre éditeurs de logiciels RH et paie.

Checklist courte

  • policies RLS sur toutes les tables sensibles ;
  • rôle manager limité à son périmètre réel ;
  • documents stockés avec contrôle d'accès cohérent ;
  • exports bornés par organisation ;
  • journaux et back-office non ouverts trop largement.
  • Pour les éditeurs RH & Paie

    CleanIssue est spécialisé dans l'audit des logiciels RH, paie et recrutement. Si vous éditez un SIRH, un outil de paie ou un ATS en France et que vous voulez une revue externe de votre exposition avant un audit client ou une revue sécurité, voyez notre offre dédiée aux éditeurs RH & Paie.

    À retenir

  • Les RLS Supabase doivent couvrir SELECT, INSERT, UPDATE et DELETE — un seul oubli suffit.
  • Désactivez l'accès direct à l'API avec la clé anon pour les tables sensibles.
  • Auditez les Edge Functions : elles contournent souvent les RLS si elles utilisent le service role key.
  • Vous éditez un logiciel RH, paie ou recrutement ? CleanIssue réalise des audits de sécurité pour SaaS RH en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.

    Besoin d'une revue externe de votre SaaS RH ?

    Expliquez votre produit, votre stack et votre contexte client. Nous revenons vers vous avec le bon niveau de revue.

    Parler de votre audit