Checklist Sécurité SaaS Avant Lancement : les 40 Vérifications qu'on Fait en Premier (2026)

Checklist Sécurité SaaS Avant Lancement : les 40 Vérifications qu'on Fait en Premier (2026)

Une checklist sécurité SaaS avant lancement vaut plus qu'une pile de badges de conformité que vous n'avez pas encore. Voici la vérité qui dérange : la plupart des checklists de lancement vous disent quoi sécuriser sans jamais montrer comment. Celle-ci fournit le code. On développe sur Next.js et Supabase, on a vu un simple filtre tenant_id manquant permettre à un compte de test de lire les données d'un autre client, et le rapport IBM Cost of a Data Breach 2024 situe la moyenne mondiale à $4.88M. Vous n'avez pas besoin de SOC 2 pour passer en production. Vous avez besoin de la base applicative ci-dessous, groupée, exécutable, et mise en correspondance avec OWASP et NIST.

Points Clés à Retenir

• Vous n'avez besoin ni de SOC 2 ni d'un pentest pour lancer. Vous avez besoin de la base applicative ci-dessous.
• Le bug de lancement le plus dangereux est la fuite de données inter-tenants due à un contrôle tenant_id manquant.
• Ne codez jamais votre propre authentification. Utilisez Auth.js, Clerk ou Supabase Auth.
• Vérifiez les préfixes NEXT_PUBLIC_ avant de déployer. C'est le moyen le plus rapide de faire fuiter un secret.

Cette base correspond à OWASP ASVS 5.0 et au NIST Secure Software Development Framework (SSDF), les deux références auxquelles Google fait le plus confiance sur ce sujet et, fait notable, celles qu'aucun des guides les mieux classés ne prend la peine de citer.

Votre Checklist de Sécurité Avant Lancement (Version Rapide)

Voici les exigences de sécurité minimales avant de mettre en production, regroupées en six catégories. Quarante éléments. Parcourez-les du haut vers le bas, transmettez les sections de code à votre développeur, et considérez tout ce qui est marqué P0 dans le tableau de priorités ci-dessous comme un bloqueur de lancement.

Secrets et Configuration

1. .env est dans .gitignore depuis le premier commit et n'a jamais été commité.
2. Chaque préfixe NEXT_PUBLIC_ et VITE_ est audité ; aucun secret ne part vers le navigateur.
3. Les secrets serveur vivent dans un gestionnaire (variables d'environnement de la plateforme, AWS Secrets Manager, Vault), pas dans le repo.
4. Toute clé ayant un jour touché l'historique git est renouvelée avant le lancement.
5. Aucun secret n'apparaît dans les logs, les payloads d'erreur ou le bundle client.
6. Vous avez grepé le bundle compilé à la recherche de clés live (grep -r "sk_live" .next/).

Authentification et Accès

1. L'authentification repose sur une bibliothèque (Auth.js, Clerk ou Supabase Auth), pas sur du code maison.
2. Le MFA est disponible sur les comptes.
3. Les cookies de session définissent Secure, HttpOnly et SameSite.
4. Aucun JWT ni token de session n'est stocké dans localStorage.
5. Le RBAC et les rôles à moindre privilège sont appliqués côté serveur, pas seulement masqués dans l'interface.
6. Les mots de passe sont hachés avec Argon2 ou bcrypt (uniquement si vous gérez vous-même l'authentification).
7. Les flux de réinitialisation de mot de passe et de vérification d'e-mail sont testés contre les abus.

Données et Tenants

1. Chaque requête porte un filtre tenant_id.
2. Le scoping par tenant est appliqué au niveau de l'ORM ou de la couche repository, pas retenu requête par requête.
3. La sécurité au niveau des lignes (RLS) est activée et ses modes de défaillance sont compris.
4. Chaque endpoint basé sur un ID d'objet effectue un contrôle de propriété (ça élimine l'IDOR).
5. tenant_id est inclus dans les clés de cache et les chemins de stockage d'objets.
6. Les données sont chiffrées au repos et en transit.
7. Les signatures de paiement et de webhook (Stripe, etc.) sont vérifiées côté serveur.

Dépendances et Chaîne d'Approvisionnement

1. npm audit ou pnpm audit ne remonte aucune faille high ou critical (ou elles sont explicitement triées).
2. Dependabot ou Renovate est activé.
3. Snyk ou Socket effectue une SCA plus poussée ainsi que des contrôles de malware et de licence.
4. Le lockfile est commité.
5. Aucun package abandonné ou non maintenu ne se trouve sur le chemin critique.
6. Les images de conteneur sont scannées si vous déployez avec Docker.

Réseau et Transport

1. HTTPS est imposé partout, avec HSTS preload.
2. Une Content-Security-Policy est définie (d'abord en mode report-only, puis appliquée).
3. X-Content-Type-Options: nosniff et X-Frame-Options/frame-ancestors sont définis.
4. Referrer-Policy et Permissions-Policy sont définis.
5. Le CORS utilise une allow-list, jamais * avec les credentials.
6. Le rate limiting protège l'authentification et les endpoints coûteux.
7. Chaque endpoint valide ses entrées avec un schéma (Zod ou équivalent).

Supervision et Réponse

1. Des logs d'audit centralisés enregistrent qui a accédé à quoi, et quand.
2. La gestion des erreurs ne fait jamais fuiter de stack trace vers les utilisateurs.
3. Des alertes se déclenchent sur les anomalies d'authentification (pics d'échecs de connexion, déplacements impossibles).
4. Des sauvegardes automatisées tournent, et vous avez testé une restauration.
5. Un contact de réponse aux incidents et un runbook d'une page existent.
6. La supervision de l'uptime et des erreurs (Sentry ou équivalent) est en place.
7. Vous connaissez le déclencheur pour faire appel à un pentest.

Priorités : Que Corriger en Premier

Tous les éléments ne bloquent pas le lancement. Ce tableau de tri classe la base selon les dégâts en cas d'omission, pour qu'un fondateur sache ce qui est non négociable. P0 = à corriger avant le lancement, P1 = à corriger en semaine un, P2 = à corriger dans le trimestre.

Secrets et Configuration : des Clés Fuient-elles Dans Votre Bundle Client ?

Une bonne hygiène des secrets au lancement signifie qu'aucun identifiant n'atteint jamais le navigateur. Le préfixe NEXT_PUBLIC_ dans Next.js (et VITE_ dans Vite) envoie une valeur à chaque visiteur, donc un seul préfixe mal placé fait fuiter une clé. Gardez .env hors de git, placez les secrets serveur dans un gestionnaire, et grepez votre build avant de déployer.

Voici le piège qu'on rencontre le plus souvent : NEXT_PUBLIC_ ne veut pas dire « information publique ». Ça veut dire « j'envoie littéralement ceci au navigateur de chaque visiteur ». Préfixez ainsi un secret Stripe ou une clé service-role, et elle se retrouve en clair dans le bundle, accessible à quiconque ouvre les DevTools.

# .env.local (l'erreur)
NEXT_PUBLIC_STRIPE_SECRET=sk_live_51H...   # MAUVAIS : part vers chaque navigateur
STRIPE_SECRET_KEY=sk_live_51H...           # OK : serveur uniquement

# Public (sans risque à exposer) vs serveur uniquement
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...       # la clé anon est censée être publique
SUPABASE_SERVICE_ROLE_KEY=eyJ...           # ne jamais préfixer en NEXT_PUBLIC_

# Repérer une clé qui a fuité avant de déployer
grep -r "sk_live" .next/    # tout résultat signale un secret dans le bundle client

Le reste de la base secrets est ennuyeux et non négociable : .env dans .gitignore dès le premier commit, secrets serveur dans un gestionnaire plutôt que dans le repo, et rotation de toute clé ayant un jour touché l'historique git (supprimer un commit ne fait pas disparaître la fuite). Un token de déploiement qui fuite, c'est exactement comme ça que démarrent des incidents comme le piratage de Vercel — traitez donc chaque token comme s'il figurait déjà sur la liste de surveillance de quelqu'un.

Authentification et Accès : Faut-il Coder Son Auth ou Utiliser une Bibliothèque ?

Faut-il coder son authentification ou utiliser une bibliothèque ? Utilisez presque toujours une bibliothèque. Auth.js, Clerk et Supabase Auth ont absorbé des années de cas limites que vous redécouvririez sinon en production : fixation de session, révocation de token, abus du flux de réinitialisation. Coder son propre système ne se justifie qu'avec un ingénieur sécurité dédié et une raison qu'aucun fournisseur ne couvre, ce qui est rare.

Coder sa propre authentification est le moyen le plus coûteux d'économiser $25 par mois. Voici comment se comparent honnêtement les options.

Deux pièges coulent les équipes qui choisissent une bibliothèque mais bâclent la config. D'abord, la révocation de JWT est réellement difficile, donc un token volé reste valide jusqu'à son expiration ; gardez des durées de vie de token courtes et préférez les sessions côté serveur pour tout ce qui est sensible. Ensuite, les tokens dans localStorage sont volables par n'importe quel payload XSS, donc stockez les sessions dans des cookies httpOnly avec Secure et SameSite. Appliquez le RBAC côté serveur, pas en masquant des boutons dans l'interface.

Si votre SaaS embarque une fonctionnalité IA ou LLM, traitez aussi l'entrée du modèle comme une frontière d'authentification non fiable. Consultez notre guide sur la prévention de l'injection de prompt, car un assistant jailbreaké avec accès à des outils est un problème de contrôle d'accès déguisé en fenêtre de chat.

Données et Tenants : Comment Empêcher un Tenant de Lire les Données d'un Autre ?

L'isolation des tenants signifie que chaque requête, clé de cache et chemin de stockage est scopé au tenant courant. Un filtre tenant_id manquant permet à un client de lire les données d'un autre, le bug de lancement le plus dangereux qui soit. La row-level security aide, mais c'est une ceinture de sécurité, pas un champ de force : ajoutez donc aussi des contrôles de propriété sur chaque endpoint à ID d'objet.

C'est la section qu'aucun concurrent ne traite avec du code, et c'est la raison pour laquelle des fuites inter-tenants se glissent en production. Le correctif commence par ne jamais faire confiance à un ID isolé. Scopez chaque lecture au tenant de l'appelant, et appliquez-le au niveau de la couche de données pour que personne n'ait à s'en souvenir requête par requête.

// MAUVAIS : aucun scope tenant. N'importe quel id valide renvoie la ligne de n'importe quel tenant.
const order = await db.order.findFirst({ where: { id } });

// BON : scopé au tenant de l'appelant sur chaque lecture.
const order = await db.order.findFirst({
  where: { id, tenantId: session.tenantId },
});

L'échec associé est l'IDOR (insecure direct object reference), que l'OWASP API Security Top 10 classe sous API1 : Broken Object Level Authorization. Un compte de test incrémente un ID dans l'URL et lit un enregistrement qu'il ne devrait jamais voir. La Web Security Academy de PortSwigger propose un tutoriel complet sur la façon dont les attaquants trouvent ces failles. Le correctif tient en un seul contrôle de propriété.

// GET /api/invoices/1234, un compte de test incrémente l'id
// et lit la facture d'un autre tenant. Un BOLA classique.
const invoice = await db.invoice.findUnique({ where: { id } });

// Correctif : vérifier la propriété avant de renvoyer quoi que ce soit.
if (invoice.tenantId !== session.tenantId) {
  return res.status(403).json({ error: "Forbidden" });
}

Voici le cadre qui vous garde honnête : tout IDOR est un échec d'isolation des tenants, mais tout échec d'isolation des tenants n'est pas un IDOR. La row-level security de Postgres en intercepte beaucoup au niveau de la base de données, mais elle a des modes de défaillance silencieux qu'il vaut mieux connaître avant de s'y fier.

-- RLS Postgres : une ceinture de sécurité, pas un champ de force.
alter table orders enable row level security;

create policy tenant_isolation on orders
  using (tenant_id = current_setting('app.tenant_id')::uuid);
-- Piège de l'échec silencieux : oubliez de faire SET app.tenant_id sur une
-- connexion poolée, et la policy lit le tenant de la requête PRÉCÉDENTE.

La contamination de pool de connexions, les fuites de contexte asynchrone et l'empoisonnement de cache partagé contournent tous la RLS en silence, c'est pourquoi le OWASP Multi-Tenant Security Cheat Sheet recommande aussi de préfixer les clés de cache et les chemins de stockage par le tenant. Le chapitre contrôle d'accès de l'OWASP ASVS 5.0 et la documentation RLS de Supabase sont les deux références à lire intégralement ici.

Dépendances et Chaîne d'Approvisionnement : Qu'est-ce Qui se Cache Dans Votre node_modules ?

Votre application n'est pas plus sûre que sa dépendance transitive la plus fragile. Lancez npm audit ou pnpm audit en CI et faites échouer le build en cas de faille high ou critical, avant même de songer à lancer. Ajoutez Dependabot ou Renovate pour les mises à jour automatiques, et Snyk ou Socket pour des contrôles plus poussés de malware et de licence.

Le piège consiste à lancer l'audit une fois à la main, voir du vert, et ne plus jamais le relancer. Intégrez-le à la CI pour qu'une nouvelle CVE dans un package que vous n'avez pas touché bloque quand même le merge.

# .github/workflows/ci.yml : bloque le merge en cas de high/critical
- name: Audit dependencies
  run: npm audit --audit-level=high    # un exit code non nul fait échouer le job

La documentation npm audit couvre les niveaux de sévérité et le flag --production si vous voulez ignorer les findings réservés au dev. Le scan automatisé reste toutefois le strict minimum ; pour une analyse statique plus poussée qui repère les code smells et les chemins d'injection qu'un scanner de dépendances rate, consultez notre avis sur SonarQube. Commitez votre lockfile, abandonnez les packages sans release depuis des années, et scannez votre image de conteneur si vous déployez avec Docker.

Réseau et Transport : de Quels En-têtes de Sécurité un SaaS a-t-il Vraiment Besoin ?

De quels en-têtes de sécurité un SaaS a-t-il besoin ? HTTPS plus HSTS et un jeu d'en-têtes restreint referment les failles les plus faciles à exploiter. Ajoutez une Content-Security-Policy, une allow-list CORS plutôt qu'un joker, et des limites de débit sur l'authentification et les endpoints coûteux. Validez chaque entrée avec un schéma comme Zod pour que les mauvais payloads n'atteignent jamais votre logique.

Vous n'avez pas besoin de tous les en-têtes jamais inventés. Vous avez besoin de cette courte liste, et la référence MDN sur les en-têtes de sécurité explique chacun d'eux en détail.

Définissez les en-têtes une fois, en périphérie (edge), et ajoutez un rate limiter pour qu'un script ne puisse pas bruteforcer votre route de connexion toute la nuit.

// next.config.js : en-têtes de sécurité sur chaque réponse
const securityHeaders = [
  { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains; preload" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
];
// Rate limiting sur les routes d'auth (exemple Upstash)
const { success } = await ratelimit.limit(ip);
if (!success) return new Response("Too many requests", { status: 429 });

Démarrez votre CSP en report-only pour ne pas casser votre propre application, surveillez les rapports de violation pendant quelques jours, puis basculez en mode enforce. Gardez le CORS limité à une allow-list nommée, et ne combinez jamais * avec les credentials.

Supervision et Réponse : Comment Saurez-vous Que Vous Avez Été Piraté ?

Vous ne pouvez pas réagir à ce que vous ne voyez pas. Avant le lancement, mettez en place des logs d'audit centralisés, des alertes sur les anomalies d'authentification comme les pics d'échecs de connexion, des sauvegardes automatisées avec une restauration testée, et un runbook d'incident d'une page. Une sauvegarde non testée est un espoir, pas une sauvegarde, et le moment d'écrire le runbook, c'est maintenant, pas en plein incident.

Les données d'IBM situent le temps moyen pour identifier et contenir une intrusion à 258 jours, et vous ne pouvez pas réduire ce chiffre si vos logs n'enregistrent pas qui a touché quoi. Centralisez-les, alertez sur les anomalies qui comptent (pics d'échecs de connexion, connexions à déplacement impossible, volume d'export soudain), et assurez-vous que votre gestionnaire d'erreurs renvoie un message propre plutôt qu'une stack trace qui cartographie vos entrailles.

La détection moderne d'intrusions s'appuie sur la surveillance des anomalies plutôt que sur des règles statiques ; on détaille comment ça fonctionne réellement dans notre article sur comment l'IA prévient les violations de données. Pour l'appui du framework, le NIST SSDF (SP 800-218) expose en langage clair les pratiques de réponse et de supervision. Testez une restauration avant le lancement, pas après la disparition de votre base de données.

Ce Qu'on Trouve Vraiment Quand On Audite Nos Propres Lancements

Quand notre équipe fait passer une revue de sécurité avant lancement sur un build, le nôtre ou celui d'un client, deux manques ressortent plus que tout le reste. D'abord : un secret qui se glisse dans le navigateur via un préfixe NEXT_PUBLIC_, généralement une clé API tierce que quelqu'un a préfixée ainsi pour faire fonctionner un appel côté client. Ensuite : au moins un endpoint sans scope tenant_id ou sans contrôle de propriété.

Le manque de scope tenant est le plus effrayant parce que l'application a l'air normale. Chaque page se charge. Le bug ne se révèle que lorsque quelqu'un modifie un ID dans l'URL. Lors d'une revue, GET /api/orders/:id renvoyait n'importe quelle commande à n'importe quel utilisateur connecté ; un compte de test a lu les commandes d'un autre tenant en incrémentant le numéro. Le correctif tenait en deux lignes : comparer order.tenantId à session.tenantId avant de renvoyer quoi que ce soit.

On ne va pas vous sortir un faux taux de détection ici. Ce qui est honnête et reproductible, c'est ceci : la fuite NEXT_PUBLIC_ et le scope tenant manquant sont les deux choses qu'on retrouve dans presque chaque première revue, et toutes deux coûtent peu à corriger une fois qu'on sait où regarder. C'est exactement pour ça que la checklist les place en priorité P0.

Si vous préférez qu'une équipe fasse cette revue à votre place avant le jour du lancement, c'est exactement ce qu'on fait. Demandez une revue de sécurité avant lancement →

Foire Aux Questions

Que Doit Contenir une Checklist de Sécurité SaaS Avant Lancement ?

Six catégories : secrets et configuration (garder les clés hors du bundle client), authentification et accès (utiliser une bibliothèque, ajouter le MFA), données et tenants (scoping tenant_id plus contrôles de propriété), dépendances (npm audit en CI), réseau et transport (HTTPS, HSTS, CSP, rate limits), et supervision et réponse (logs d'audit, sauvegardes testées, un runbook).

Mon SaaS Est-il Assez Sécurisé Pour Être Lancé ?

Vous êtes prêt quand la base P0 est faite : secrets hors du bundle client, isolation des tenants sur chaque requête, authentification sur une bibliothèque, HTTPS avec en-têtes de sécurité, et un scan de dépendances propre. La perfection n'est pas le critère. Une application lancée et supervisée avec la base couverte vaut mieux qu'une application « parfaite » qui ne sort jamais.

Ai-je Besoin d'un Test d'Intrusion Avant de Lancer un SaaS ?

Pas pour lancer légalement. Priorisez-en un si vous gérez des paiements ou des données personnelles, ciblez des acheteurs enterprise, ou si un auditeur ou un investisseur le demande. Au stade MVP, consacrez plutôt cet effort à la base applicative et à l'OWASP Top 10. Un pentest trouve davantage de choses une fois que les failles IDOR et d'en-têtes évidentes sont déjà fermées.

Ai-je Besoin de SOC 2 Pour Lancer un SaaS ?

Non. Aucun client n'attend de SOC 2 de la part d'une startup lancée la semaine dernière. C'est un déblocage pour la vente enterprise, pas un prérequis de lancement, et ça prend des mois. Lancez avec la base applicative, puis démarrez le processus SOC 2 quand un vrai deal enterprise l'exige, pas avant.

Dois-je Coder Ma Propre Authentification ou Utiliser une Bibliothèque Comme Auth.js, Clerk ou Supabase Auth ?

Utilisez presque toujours une bibliothèque. Auth.js, Clerk et Supabase Auth ont déjà géré les cas limites de session, de token et de flux de réinitialisation qui causent la plupart des bugs d'auth maison. Coder sa propre solution ne se justifie que si vous avez un ingénieur sécurité et une exigence stricte qu'aucun fournisseur ne remplit, ce qui est vraiment rare.

Comment Garder les Secrets Hors de Mon Bundle Client ?

Auditez chaque préfixe NEXT_PUBLIC_ et VITE_, car tout ce qui porte ce préfixe part vers le navigateur. Gardez .env hors de git dès le premier commit, stockez les secrets serveur dans un gestionnaire, et grepez votre bundle compilé (grep -r "sk_live" .next/) avant de déployer pour repérer une clé qui a fuité.

Comment Isoler les Données des Tenants Dans un SaaS Multi-tenant ?

Mettez un filtre tenant_id sur chaque requête et appliquez-le au niveau de l'ORM ou de la couche repository pour que ce soit automatique. Activez la row-level security et apprenez ses modes de défaillance (contamination de pool, fuites asynchrones). Ajoutez un contrôle de propriété à chaque endpoint à ID d'objet pour fermer l'IDOR, et scopez les clés de cache et les chemins de stockage par tenant.

Quels En-têtes de Sécurité un SaaS Doit-il Avoir Avant Lancement ?

Au minimum : Strict-Transport-Security (HSTS), une Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options ou frame-ancestors, Referrer-Policy, et Permissions-Policy. Démarrez votre CSP en report-only, examinez les violations, puis appliquez-la. La documentation MDN sur les en-têtes de sécurité liste les valeurs recommandées pour chacun, et le tableau ci-dessus résume ce que chacun bloque.

Le Scan Automatisé Comme npm Audit ou Snyk Suffit-il ?

Nécessaire mais pas suffisant. Des outils comme npm audit, Snyk et Socket détectent les CVE connues et les packages malveillants, mais ils ne peuvent pas trouver les failles de logique métier et de contrôle d'accès comme l'IDOR ou un scope tenant manquant. Celles-ci nécessitent un humain, un compte de test, et un contrôle de propriété explicite. Faites les deux : le scanner et une revue manuelle.

En Résumé : une Checklist Sécurité SaaS Que Vous Pouvez Vraiment Déployer

Vous n'avez pas besoin d'être parfait pour lancer. Vous avez besoin de la base. Fermez d'abord les éléments P0 : secrets hors du bundle, isolation des tenants sur chaque requête, contrôle de propriété sur chaque endpoint d'objet, authentification sur une bibliothèque, et HTTPS avec en-têtes. Si vous ne corrigez qu'une seule chose avant le lancement de vendredi, que ce soit l'isolation des tenants, car c'est le bug qui fait fuiter les données d'un client sans le moindre avertissement.

Tout ce qui est ici est exécutable dès aujourd'hui, et rien de tout ça n'exige un budget conformité. Parcourez les 40 vérifications, transmettez les sections de code à votre développeur, et lancez. Envie d'un second regard avant de passer en production ? Demandez une consultation gratuite et on parcourt la liste avec vous.