Sécuriser son SaaS

CHAPITRE 1 — PERSONNE N'EST TROP PETIT POUR ÊTRE PIRATÉ

J'ai passé une partie de ma carrière à auditer des applications. Des SaaS de deux semaines, des plateformes avec des milliers d'utilisateurs, des projets vibecodés un dimanche. Et à chaque audit, le même schéma revient : ce ne sont presque jamais des attaques géniales qui cassent une app. Ce sont des portes laissées ouvertes.

Une clé API commitée dans Git. Une table sans règle d'accès. Un formulaire qui avale tout ce qu'on lui donne. Des erreurs tellement courantes qu'elles ont un classement officiel — et tellement évitables qu'un week-end sérieux suffit à fermer la quasi-totalité d'entre elles.

C'est exactement ce qu'on va faire ensemble. Cet ebook, c'est l'audit que je facturerais à ton SaaS, transformé en méthode que tu peux dérouler toi-même.

§Le mythe qui fait tomber les petits projets

« Personne ne va m'attaquer, mon app a 30 utilisateurs. »

C'est la phrase que j'entends le plus souvent. Et elle repose sur une erreur de représentation : tu imagines un pirate humain, assis dans le noir, qui choisit sa cible. Ce pirate existe, mais ce n'est pas lui qui va te trouver.

Ce qui va te trouver, c'est un bot : un programme automatique qui scanne Internet en permanence, adresse par adresse, à la recherche de portes ouvertes connues. Ton app est en ligne depuis quelques heures ? Elle a déjà reçu ses premières visites de bots. Ils ne savent pas qui tu es et s'en fichent. Ils testent les mêmes failles sur des millions de sites, et récoltent tout ce qui cède.

Pour un bot, ton SaaS de 30 utilisateurs et une banque, c'est le même travail : une URL à tester. La différence, c'est que la banque a une équipe sécurité. Toi, tu as cet ebook.

§Les chiffres, pour poser le décor

Je ne vais pas te faire peur avec des scénarios hypothétiques. Voici ce que disent les données réelles — chaque chiffre est sourcé, tu trouveras toutes les références en fin d'ouvrage.

• 22 000 fuites de données confirmées analysées dans le rapport Verizon DBIR 2026, le plus gros jeu de données de l'histoire du rapport. Pas des tentatives : des fuites réelles.
• Pour la première fois en 19 ans, l'exploitation de vulnérabilités est devenue le premier point d'entrée des attaques (environ 31 % des cas), devant le vol d'identifiants. Traduction : les attaquants trouvent des failles dans le code et la config plus souvent qu'ils ne volent des mots de passe.
• L'élément humain est présent dans 62 % des fuites : une erreur, un clic, une mauvaise config. La sécurité n'est pas qu'un problème de code.
• Le coût moyen d'une fuite de données : 4,44 millions de dollars au niveau mondial (IBM, 2025). Ton SaaS ne perdra pas 4 millions — il perdra ses utilisateurs, sa réputation, et probablement son avenir juridique. C'est proportionnellement pire.

Et un chiffre qui te concerne directement si ton code est écrit par une IA : 45 % du code généré par les grands modèles contient une faille de sécurité dans les tests de Veracode sur plus de 100 modèles. On y consacrera un chapitre entier, parce que c'est la nouvelle réalité de la sécurité applicative.

§Deux mots à installer avant tout

Toute la suite de l'ebook repose sur deux notions. Prenons trente secondes pour les poser proprement — c'est la méthode de cet ouvrage : aucun terme technique ne restera flou.

Une vulnérabilité, c'est un défaut dans ton application qui permet de lui faire faire quelque chose de non prévu. Pense à une maison : la serrure qui s'ouvre avec une carte de fidélité, la fenêtre du sous-sol qui ne ferme pas. La maison fonctionne très bien au quotidien — le défaut ne se voit que quand quelqu'un l'exploite.

Un vecteur d'attaque, c'est le chemin qu'emprunte l'attaquant pour exploiter une vulnérabilité. La fenêtre du sous-sol, c'est la vulnérabilité ; passer par le jardin de nuit pour l'atteindre, c'est le vecteur.

Tout ton travail de sécurisation consiste à faire deux choses : réduire le nombre de fenêtres mal fermées, et rendre les chemins vers celles qui restent les plus pénibles possible. Les professionnels appellent ça réduire la surface d'attaque — la somme de tous les points par lesquels ton app peut être atteinte.

§Ce que cet ebook te promet — et ce qu'il ne te promet pas

Soyons précis, parce que c'est un sujet où le marketing ment beaucoup.

Ce que cet ebook couvre : la totalité des catégories de failles qui causent les piratages réels d'applications web — celles répertoriées par l'OWASP, l'organisme de référence mondial qu'on présentera au chapitre suivant, croisées avec les données de terrain des rapports Verizon et IBM. Si tu appliques la méthode chapitre par chapitre, ton SaaS sera blindé contre tout ce qui fait tomber les apps aujourd'hui : les fuites de données, les comptes volés, les bases aspirées, les clés exposées.

Ce qu'aucun livre, aucun outil et aucun consultant ne peut te promettre : le risque zéro absolu. Un auditeur qui te promet ça te ment — c'est même un bon test pour reconnaître les charlatans. Ce qui existe, c'est une app dont la surface d'attaque est maîtrisée, surveillée, et dont chaque porte connue est fermée à clé. C'est exactement là où tu seras à la fin.

§Où on va, du premier chapitre au dernier

Cet ebook suit l'ordre exact d'un audit réel. Trois temps, et une destination.

Temps 1 — Comprendre (chapitres 1 et 2). Tu installes les trois outils mentaux de l'auditeur : le modèle de menace, la carte des quatre couches de ton SaaS, et la grille OWASP. Sans cette carte, on audite à l'aveugle et on sécurise au hasard.

Temps 2 — Fermer les portes, une par une (chapitres 3 à 9). Le cœur du livre. On descend couche par couche, dans l'ordre du dégât potentiel : qui entre (3), ce qu'il a le droit de toucher (4), ce qu'il t'envoie (5), ce qui traîne déjà chez toi (6), ce que tu as installé sans le lire (7), ce que l'IA a écrit à ta place (8), et pour finir l'argent et les données personnelles (9). Chaque chapitre reprend là où le précédent s'arrête — c'est une progression, pas un catalogue.

Temps 3 — Valider et maintenir (chapitre 10). Tout converge ici. Tu y trouveras la checklist maîtresse, classée par criticité : 🔴 ce qui interdit un déploiement, 🟠 ce qui doit être réglé avant d'avoir de vrais utilisateurs, 🟡 la finition d'un pro. Plus les outils gratuits qui vérifient ton travail à ta place, le plan à suivre si un jour ça tourne mal, et la totalité des sources.

La destination : à la dernière page, tu as déroulé un audit complet sur ton app, tu sais lesquelles de tes failles étaient graves et lesquelles étaient cosmétiques, et tu repars avec une page de référence — le chapitre 10 — que tu rouvriras à chaque déploiement.

Lis dans l'ordre la première fois. Ensuite, seul le chapitre 10 se relit.

Dans le prochain chapitre, on inverse les rôles : tu vas apprendre à regarder ton propre SaaS avec les yeux de celui qui veut le casser.