Checklist de sécurité SaaS : 10 contrôles indispensables avant la mise en production
La checklist technique pas à pas pour sécuriser votre SaaS avant d'accueillir vos premiers clients : RLS, clés API privées, failles IDOR, webhooks Stripe et rate limiting.
Avant de lancer un SaaS en production, 10 vérifications sont indispensables : activer Row-Level Security sur toutes les tables Supabase, vérifier que les clés secrètes (Stripe, OpenAI) ne sont pas injectées dans le bundle client, vérifier les signatures cryptographiques des webhooks, et limiter le débit (rate limiting) sur les routes d'authentification.
1. Accès aux données & Row-Level Security (RLS)
Sur PostgreSQL et Supabase, RLS est désactivé par défaut lors de la création manuelle d'une table. Quiconque détient la clé anon (publique dans le code source de la page web) peut lire ou modifier l'intégralité de la table si aucune policy n'est appliquée.
- **Vérification 1 :** Assurez-vous que chaque table publique possède `ENABLE ROW LEVEL SECURITY`.
- **Vérification 2 :** Ne laissez jamais de policy `USING (true)` en production sans filtre sur `auth.uid()`.
- **Vérification 3 :** Définissez une policy explicite pour chaque opération (`SELECT`, `INSERT`, `UPDATE`, `DELETE`).
-- Vérifier les tables sans RLS dans votre base Supabase
SELECT tablename
FROM pg_tables
WHERE schemaname = 'public'
AND rowsecurity = false;2. Clés API et fuites de secrets dans le client JS
Dans les frameworks comme Next.js ou Vite, toute variable préfixée par `NEXT_PUBLIC_` ou `VITE_` est compilée directement dans le fichier JavaScript téléchargé par le navigateur de l'utilisateur.
- **Vérification 4 :** Aucune clé Stripe secrète (`sk_live_`), token OpenAI (`sk-`) ou clé Supabase `service_role` ne doit être accessible côté client.
- **Vérification 5 :** Inspectez les requêtes réseau dans la console DevTools du navigateur pour vérifier qu'aucun appel direct n'est fait aux API tierces sans passer par vos routes serveurs.
3. Authentification & Prévention des failles IDOR
Une faille IDOR (Insecure Direct Object Reference) survient lorsqu'une route accepte un identifiant d'objet (ex: `/api/invoices/9482`) sans s'assurer que la ressource appartient bien au compte authentifié.
- **Vérification 6 :** Sur chaque Server Action ou route API, validez systématiquement que l'utilisateur connecté est le propriétaire de la ressource demandée.
- **Vérification 7 :** Activez un rate-limiter (comme Upstash Redis ou un middleware de rate-limiting) sur les formulaires d'inscription et de réinitialisation de mot de passe.
4. Webhooks tiers et stockage
Les intégrations de paiement sont les cibles privilégiées des attaquants :
- **Vérification 8 :** Vérifiez impérativement la signature cryptographique des webhooks Stripe (`stripe.webhooks.constructEvent`) avant de créditer un compte ou débloquer un abonnement.
- **Vérification 9 :** Assurez-vous que vos buckets de stockage (S3, Supabase Storage) ne sont pas configurés en "Public" s'ils hébergent des factures ou des documents confidentiels.
- **Vérification 10 :** Configurez des headers de sécurité stricts (`Content-Security-Policy`, `Strict-Transport-Security`, `X-Content-Type-Options: nosniff`).
Questions fréquentes
Quelle est la faille la plus fréquente sur les nouveaux SaaS ?
L'oubli d'activer la Row-Level Security (RLS) sur Supabase ou la mauvaise configuration d'une policy USING (true), qui expose l'ensemble de la base de données via l'API REST publique.
Comment savoir si mes clés API privées sont visibles ?
Ouvrez les outils de développement de votre navigateur (F12), allez dans l'onglet 'Sources' ou 'Network', et recherchez des motifs comme 'sk_live_' ou 'service_role'.
Votre SaaS est-il prêt pour la production ?
Identifiez vos failles critiques avant vos utilisateurs avec la Security Review Validra sous 5 jours ouvrés.