Auditer son SaaS avant de shipper : retour d'expérience

J’ai passé des soirées à coder un outil qui cherche des failles de sécurité. Puis je l’ai lâché sur mes propres SaaS. Sur Copyboost, il n’a presque rien dit. Sur Zovalide, il a trouvé un trou qui laissait n’importe quel utilisateur s’offrir mon plan le plus cher gratuitement. Et au passage, mon SaaS multi-tenant a appris une leçon entière à mon outil.

Je ne suis pas développeur. Je build avec Claude Code, sans avoir appris à coder. Voici ce que ça donne quand un fondateur non technique audite son code avant de shipper, sans payer un cabinet de sécurité plusieurs milliers d’euros.

Pourquoi j’ai lâché mon propre outil de sécurité sur mes deux SaaS

Tout part d’une idée simple. Tu ne shippes pas un produit sans vérifier qu’il ne fuit pas.

Le souci, quand tu build sans savoir coder, c’est que tu ne sais pas ce que tu ne sais pas. Une faille de sécurité, ça ne lève pas d’erreur dans le terminal. Le site marche, les paiements passent, et tu dors tranquille. Jusqu’au jour où quelqu’un trouve le trou que tu n’as jamais regardé.

Alors j’ai codé mon propre auditeur, saas-preflight. Un skill open source qui passe au crible une stack Next.js, Supabase et Stripe, la même que celle derrière tous mes produits. Il a démarré avec 7 lentilles d’analyse. Il en a 8 aujourd’hui, et c’est mon propre SaaS qui m’a forcé à ajouter la dernière.

La règle que je me suis fixée : ne jamais faire confiance à l’outil sur parole. Je le teste sur mon propre code d’abord. On appelle ça le dogfooding. Manger sa propre nourriture.

Faut-il auditer son SaaS soi-même avant de le lancer ?

Oui, surtout si tu build avec l’IA sans background technique. Un audit maison ne remplace pas un pentest pro, mais il attrape les fautes les plus communes : permissions trop larges, validation absente, secrets exposés. La majorité des failles d’un SaaS solo ne sont pas sophistiquées. Elles sont juste invisibles tant que personne ne regarde.

Le mythe, c’est de croire que la sécurité, c’est pour les grosses boîtes avec une équipe dédiée. Faux. Les failles les plus bêtes touchent surtout les produits buildés vite, par une seule personne, avec des outils qui génèrent du code à la chaîne.

Claude Code écrit du bon code la plupart du temps. Mais il écrit ce que tu lui demandes. Si tu ne penses pas à verrouiller une permission, il ne la verrouille pas tout seul. Le résultat tient en une phrase : ton produit fait exactement ce que tu as oublié de lui interdire.

Tu audites ton code avant la prod ? Fais pareil avec ta copy. Avant d’envoyer ta prochaine page de vente, passe-la au Diagnostic de Performance sur copyboost.io. C’est gratuit, et ça te montre comment ton audience va réagir avant que tu appuies sur Publier.

Copyboost : quand l’audit se tait, c’est une victoire

Premier test. Je lance saas-preflight sur Copyboost, mon outil d’audit de copy, dont je raconte les six mois de construction dans mon retour sur le lancement.

Verdict : sain. Et ça, c’est la meilleure nouvelle qu’un audit puisse te donner.

Les deux failles que j’avais déjà fermées

Lors d’un premier passage, des mois plus tôt, l’outil avait remonté deux problèmes classés P1. Un SSRF sur le scraper, le genre de faille où une requête peut être détournée vers une adresse interne. Et un webhook Stripe mal verrouillé.

Les deux étaient déjà corrigés. Le second audit l’a confirmé en silence. Pas de nouvelle alerte. C’est exactement ce que tu veux voir quand tu repasses sur du code que tu pensais propre.

La fausse alerte qui m’a appris à rester prudent

Là, l’outil a sonné. Un sous-domaine de Copyboost et un wildcard ressemblaient à un subdomain takeover, le scénario où un attaquant récupère un sous-domaine abandonné pour se faire passer pour toi.

J’ai creusé avant de paniquer. Résultat : c’est le comportement par défaut de Vercel pour un domaine géré par ses serveurs de noms. La propriété du sous-domaine reste verrouillée sur mon compte via une vérification TXT. Donc pas de takeover exploitable.

La leçon n’est pas technique. Elle est méthodologique. Un outil qui lève une alerte ne dit pas la vérité, il dit « regarde ici ». Si un jour un attaquant contrôlait réellement un de ces sous-domaines, le risque existerait. Aujourd’hui, non. Vérifie toujours avant d’affirmer.

Zovalide : le P0 qui offrait mon plan le plus cher gratuitement

Deuxième test. Je lance l’audit sur Zovalide, mon portail d’approbation de contenu en marque blanche. Et là, l’outil mord.

P0. La classification la plus haute. La faille que tu corriges avant de faire quoi que ce soit d’autre.

Le scénario, prouvé en conditions réelles : n’importe quel utilisateur connecté pouvait passer son compte sur le plan Agency, l’offre la plus chère, sans payer un centime. Il suffisait de modifier une valeur que je n’avais jamais pensé à protéger : le champ plan dans la table des profils.

Mon outil de sécurité venait de trouver, à coût zéro, un trou qui me faisait perdre du revenu en silence. Pas un crash. Pas une erreur. Juste une porte ouverte que personne n’avait remarquée.

C’est quoi une faille de mass assignment, en clair ?

Une faille de mass assignment, c’est quand ton code laisse un utilisateur modifier des champs qu’il ne devrait jamais toucher. Tu autorises la mise à jour d’un profil pour le nom et l’avatar, mais sans restreindre les colonnes, l’utilisateur peut aussi modifier son niveau d’abonnement, son quota ou son statut. Il s’assigne en masse des droits qu’il n’a pas payés.

L’image que j’utilise pour moi-même : c’est un formulaire d’inscription où tu remplis ton nom et ton email, mais où un champ caché est_administrateur traîne dans le code. Si rien ne bloque ce champ, je coche la case, et je deviens admin.

Sur Zovalide, le champ sensible n’était pas l’admin. C’était le plan tarifaire. Même principe, même danger.

C’est ce type de détail qui transforme un produit qui marche en produit qui fuit. Une virgule de configuration oubliée peut tout faire basculer, exactement comme un petit bug a pu provoquer de gros dégâts ailleurs.

Comment j’ai fermé la faille

J’ai retiré le droit de mise à jour au niveau de la table pour les utilisateurs connectés. Puis j’ai redonné, colonne par colonne, uniquement ce qui est légitime : le nom complet, le nom de l’agence, la couleur de marque.

Les champs sensibles sont désormais hors de portée. Le plan, le quota de stockage, l’identifiant client Stripe ne peuvent plus être modifiés par l’utilisateur. J’ai vérifié le correctif en lecture seule sur la production. La porte est fermée.

La 8e lentille : mon SaaS multi-tenant a complété mon outil

Voici le retournement que je n’avais pas vu venir. Ce P0 ne m’a pas juste fait corriger Zovalide. Il m’a fait corriger mon outil.

Zovalide est multi-tenant. Plusieurs agences, plusieurs marques, des données qui ne doivent jamais se croiser. Mon auditeur, lui, ne testait pas l’isolation entre locataires. Il regardait le code d’un SaaS classique, pas d’un SaaS où chaque client vit dans sa propre bulle.

J’ai donc ajouté une 8e lentille, conditionnelle, dédiée à l’isolation tenant. Elle ne se déclenche que sur les architectures multi-tenant. C’est la version 1.1.0 du skill, publiée et vérifiée, avec un scanner PowerShell natif en plus du scanner bash, pour les makers qui bossent sous Windows comme moi.

Le reste de Zovalide a tenu bon : isolation correcte entre locataires, cookie limité à l’hôte, en-tête tenant nettoyé, RLS actif sur 8 tables. La faille était dans un champ, pas dans l’architecture. Mais sans ce P0, ma 8e lentille n’existerait pas. Mon produit a rendu mon outil meilleur.

Le CSRF : la section où je me suis fait peur pour rien

Un mot sur le CSRF, parce que c’est le sujet qui m’a fait perdre le plus de temps pour le plus petit gain réel.

Le CSRF, c’est une attaque où un site malveillant fait exécuter une action à ton insu sur un site où tu es connecté. La parade moderne tient souvent dans un seul réglage de cookie : SameSite=Lax. Ce réglage bloque l’envoi du cookie depuis un autre site, ce qui coupe l’attaque à la racine.

Mes deux SaaS l’ont déjà par défaut. J’ai quand même codé une garde supplémentaire, une vérification de l’origine de la requête, en défense en profondeur. Je ne l’ai pas committée. Elle reste optionnelle.

Pourquoi je la garde sous le coude ? Parce que la défense en profondeur, c’est empiler les barrières. Si une protection saute un jour, la suivante tient. Mais je refuse d’ajouter de la complexité que je ne comprends pas. Tant que SameSite=Lax fait le travail, la garde reste un bonus, pas une obligation.

Ma checklist pour auditer un SaaS avant de shipper

Voici la méthode que j’applique en 2026 avant de mettre quoi que ce soit en production. Elle ne demande pas d’être développeur. Elle demande d’être méthodique.

1. Les permissions de base de données. Vérifie que chaque table a ses règles d’accès. Sur Supabase, c’est le RLS. Pas de RLS, pas de prod.
2. Les champs modifiables par l’utilisateur. Liste ce qu’un utilisateur peut écrire. Si le plan, le quota ou un statut admin sont dedans, ferme la porte au niveau colonne.
3. Les webhooks de paiement. Stripe envoie des événements. Vérifie la signature de chaque événement, sinon n’importe qui peut en falsifier un.
4. Les requêtes sortantes. Si ton app va chercher une URL fournie par l’utilisateur, encadre-la. C’est la porte du SSRF.
5. Les cookies de session. SameSite=Lax au minimum. Cookie limité à l’hôte. Pas de session qui traîne sur tout le domaine.
6. L’isolation des données. Si tu es multi-tenant, teste qu’un client ne peut jamais voir les données d’un autre. C’est la faille la plus chère à découvrir trop tard.

Tu n’as pas besoin de tout coder à la main. Tu as besoin de poser chaque question et de vérifier la réponse. Un outil comme saas-preflight automatise une partie de cette liste. Ton cerveau fait le reste.

Le même principe vaut pour ta copy. Avant d’envoyer une campagne, passe ton texte au Lecteur de Réactions sur copyboost.io. Tu vois le score d’émotion, le score d’urgence, et tu corriges avant l’envoi au lieu de découvrir après que personne n’a cliqué.

Ce que ce dogfooding m’a appris

Trois choses à retenir. Un audit qui se tait sur du code sain vaut autant qu’un audit qui mord, parce qu’il te dit où tu es solide. Une vraie faille se cache rarement dans l’architecture, plus souvent dans un champ oublié. Et ton propre produit peut t’apprendre des choses que ton outil ignorait, à condition de l’écouter.

Je ne sais pas si Zovalide ou Copyboost vont décoller. Mais je sais qu’ils ne fuient pas, parce que j’ai vérifié avant de shipper au lieu de croiser les doigts.

La vraie question, c’est pour toi. Ton prochain lancement, tu le shippes à l’instinct, ou tu vérifies avant ? Pour le code, tu as ta checklist. Pour ta copy, tu as le Diagnostic Copyboost. Dans les deux cas, le principe est le même : mesure avant de publier.

Dernière mise à jour : juin 2026