Sécurité application web : 5 risques invisibles

La semaine dernière, un fondateur m'a appelé en panique. Un de ses utilisateurs venait de lui envoyer un screenshot : il voyait les données de tous les autres clients. Noms, emails, montants de facturation — tout était accessible.

Son développeur lui avait assuré que l'application était sécurisée. Et sur ce qu'il connaissait, c'était vrai. L'authentification fonctionnait, le HTTPS était en place, les mots de passe étaient chiffrés. Mais il avait oublié de vérifier ce qui se passait après la connexion.

C'est un pattern que je retrouve dans presque chaque audit. Le développeur sécurise ce qu'il connaît. Le problème, c'est ce qu'il ne pense pas à vérifier.

Pourquoi votre développeur ne voit pas ces failles

Ce n'est pas une question de compétence. C'est une question de perspective.

Un développeur construit votre application de l'intérieur. Il sait comment elle fonctionne, comment les données circulent, pourquoi tel choix technique a été fait. Mais cette connaissance intime du produit crée un angle mort : il ne pense pas comme quelqu'un qui chercherait à casser ce qu'il a construit. C'est la même différence qu'entre un conducteur et un contrôleur technique. Le conducteur sait que sa voiture roule. Le contrôleur technique vérifie si elle devrait encore rouler.

Ce que j'ai constaté en auditant plus de 40 applications : la majorité des failles ne viennent pas du code, mais de ce qui est autour — les configurations serveur, les permissions de base de données, les headers HTTP, les politiques de sauvegarde. Le code peut être propre et l'application quand même vulnérable.

La sécurité est une spécialité à part entière. Demander à un développeur fullstack de sécuriser une application, c'est comme demander à un généraliste de faire de la chirurgie cardiaque. Il connaît le corps humain, mais les cas limites lui échappent.

Risque 1 — Vos API laissent la porte grande ouverte

Une startup SaaS me contacte pour un audit avant leur série A. Environ 2 000 utilisateurs, produit B2B, données sensibles. En regardant les API — les points d'accès qui servent les données — je découvre que plusieurs d'entre elles ne vérifient pas qui fait la demande.

En clair : n'importe qui connaissant l'URL pouvait récupérer la liste complète des clients, leurs contrats, leurs données de facturation. Sans mot de passe. Sans connexion. Sans rien.

Le fondateur l'a découvert de la pire manière possible : ses clients ont commencé à recevoir des offres d'un concurrent. Quelqu'un avait aspiré la base entière en une nuit. Résultat : 30% de churn dans les 3 mois, une levée reportée de 9 mois, et 6 mois à reconstruire une confiance qu'il n'a jamais totalement retrouvée.

Ce qu'il faut demander à votre dev : "Est-ce que chaque API vérifie l'identité de l'utilisateur avant de répondre ?" Si la réponse est "normalement oui" au lieu de "oui, c'est testé automatiquement" — notez la différence.

Risque 2 — Vos utilisateurs voient les données des autres

Celle-là est vicieuse, parce qu'elle ne se voit pas en test.

Un fondateur d'une application de gestion RH me contacte après un signalement. Un de ses clients voit les fiches de paie d'une autre entreprise. Pas de piratage, pas de manipulation — il a juste changé un chiffre dans l'URL. /fiche/42 est devenu /fiche/43, et c'étaient les données de quelqu'un d'autre.

Le développeur avait vérifié que l'utilisateur était connecté. Mais pas que les données demandées lui appartenaient. Le système vérifiait que vous aviez une clé, pas que cette clé ouvrait votre porte.

Au-delà du fix technique — corrigé en 2 heures — c'est la dimension RGPD qui fait mal. Des données personnelles de salariés exposées à des tiers non autorisés, c'est une violation de données au sens du règlement. Notification à la CNIL obligatoire, notification aux personnes concernées, et potentiellement une amende entre 10 000 et 100 000 € pour une PME.

Posez la question directement : "Si un utilisateur modifie un identifiant dans l'URL, est-ce qu'il accède aux données d'un autre ?" Si votre dev hésite, c'est qu'il n'a jamais testé ce scénario.

Risque 3 — Vos clés sensibles traînent dans le navigateur

Un fondateur e-commerce me demande de jeter un œil à son app avant de passer à l'échelle. En ouvrant le code source dans le navigateur — une opération que n'importe qui peut faire en 2 clics — je tombe sur sa clé Stripe. Pas la clé publique, prévue pour être visible. La clé secrète. Celle qui permet de créer des paiements, d'émettre des remboursements, d'accéder à l'historique complet des transactions.

Le développeur avait mis toutes les clés dans le même fichier de configuration côté navigateur. Il ne savait pas que tout ce qui tourne dans le navigateur est visible par l'utilisateur. C'est un truc qu'on explique rarement aux développeurs juniors, et que les outils de génération de code ne signalent jamais.

D'ailleurs, si vous avez construit votre application avec des outils comme Lovable ou Bolt, ce risque est encore plus fréquent. Ces outils génèrent du code qui fonctionne, mais ne font pas la distinction entre ce qui doit rester sur le serveur et ce qui peut aller dans le navigateur.

L'exposition financière est potentiellement illimitée. Un attaquant avec votre clé Stripe secrète peut vider votre compte — et Stripe ne vous remboursera pas. La sécurisation des clés est explicitement de votre responsabilité dans leurs conditions d'utilisation.

Risque 4 — Personne ne bloque la porte après 10 tentatives

Une app avec 800 utilisateurs. Page de connexion classique. Email, mot de passe, bouton "Se connecter". Jusque-là, rien d'anormal.

Sauf qu'un attaquant pouvait essayer 10 000 mots de passe par minute sans être bloqué, sans alerte, sans rien. L'équivalent numérique de tester toutes les clés d'un trousseau sur votre serrure — sauf qu'ici on teste des milliers de combinaisons par seconde.

Je dois reconnaître que cette faille est facile à oublier. Quand on développe une page de connexion, on se concentre sur le scénario normal : l'utilisateur entre son mot de passe, c'est bon ou c'est faux, point. Penser à l'attaquant qui va essayer en boucle, c'est un réflexe de spécialiste en sécurité, pas de développeur.

Mais les conséquences sont réelles. Si un de vos utilisateurs a un mot de passe faible — et statistiquement, au moins 20% en ont un —, c'est une question de temps avant qu'un compte tombe. Et si c'est un compte admin, l'attaquant a accès à tout.

Demandez : "Que se passe-t-il si quelqu'un essaie 100 mots de passe en une minute ?" La bonne réponse, c'est un blocage automatique après 5-10 tentatives.

Risque 5 — Vos sauvegardes n'existent pas

Ce n'est pas un risque de sécurité au sens classique. Mais c'est celui qui fait le plus mal quand il se matérialise.

Un fondateur me contacte après un crash serveur. Sa base de données est corrompue. 18 mois de données clients, de commandes, d'historique — tout est parti.

"Mais on avait des sauvegardes, non ?"

Non. Le développeur avait configuré le serveur, déployé l'application, mis en place la base de données. Mais personne n'avait configuré de sauvegardes automatiques. Le développeur partait du principe que l'hébergeur s'en chargeait. L'hébergeur partait du principe que le développeur le ferait.

18 mois de données perdues. Irréversiblement. Le fondateur a dû recontacter ses clients un par un pour reconstituer ce qu'il pouvait. Certains n'ont jamais répondu.

La question qui tue : "Quand a-t-on testé la dernière restauration de backup ?" Parce qu'avoir des sauvegardes qui n'ont jamais été testées, c'est comme avoir un extincteur dont personne ne sait s'il fonctionne. La moitié des entreprises qui pensent avoir des backups découvrent au moment du crash qu'ils sont inutilisables.

La checklist du fondateur : les 5 questions à poser maintenant

Vous n'avez pas besoin de comprendre le code pour vérifier la sécurité de votre application web. Vous avez besoin de poser les bonnes questions — et de savoir distinguer une vraie réponse d'un "normalement oui".

La règle d'or : une bonne réponse est précise et vérifiable. Une mauvaise réponse est vague ou conditionnelle.

Quand faire auditer la sécurité de votre application

Si vous lisez cet article en vous demandant si votre app est concernée — elle l'est probablement. Ces 5 risques ne sont pas des cas extrêmes. Ce sont les failles les plus courantes que je trouve en audit.

Quatre moments où un audit de sécurité est non négociable :

• Avant la mise en production — corriger une faille avant les premiers utilisateurs coûte 10 fois moins cher qu'après une fuite
• Au-delà de 100 utilisateurs — à ce stade, une fuite de données n'est plus un incident, c'est une crise
• Avant une levée de fonds — les investisseurs sérieux demandent un audit technique, et une faille de sécurité fait capoter des deals
• Après un changement de développeur — chaque dev a ses angles morts, et le nouveau ne connaît pas les raccourcis pris par l'ancien

Si vous avez construit votre app avec du vibe coding ou des outils no-code, l'audit est encore plus important. Ces outils produisent du code fonctionnel, mais la sécurité n'est pas leur priorité.

La sécurité d'une application web n'est pas un sujet technique réservé aux développeurs. C'est un risque business. Et comme tous les risques business, il se gère : en le mesurant, en le comprenant, et en le traitant avant qu'il ne coûte cher.