Sécurité applicative
Je cherche les failles, puis je les corrige dans le code.
La sécurité fait partie de chaque application que je livre depuis 25 ans, pas d'une étape ajoutée à la fin. Quand un client me demande de regarder de plus près, je procède en développeur : j'inventorie ce qui tourne, je trie par gravité, puis je corrige dans le code. Le périmètre est volontairement précis : la sécurité applicative.
Ce que je vérifie
Quatre axes, à combiner ou à prendre séparément selon ce que votre application demande.
Audit du front-end et des dépendances
La méthode éprouvée chez Saint-Gobain : inventorier chaque bibliothèque JavaScript tierce et établir, pour chacune, sa justification, sa provenance, son périmètre dans l'application et son mode de chargement (embarquée ou externe, CDN). Puis rationaliser : retirer, remplacer ou regrouper.
Failles applicatives
Revue du code et de sa configuration : injections, authentification et sessions, en-têtes HTTP et Content Security Policy, secrets oubliés dans le code ou la configuration, dépendances côté serveur.
Je corrige ce que je trouve
Je suis développeur avant d'être auditeur : les correctifs sont priorisés, puis écrits dans le code, au lieu de finir en liste de recommandations qui attend dans un tiroir. Si votre équipe préfère les appliquer elle-même, je remets un plan d'action classé par gravité.
Configurations d'assistants IA
Les fichiers qui pilotent un assistant comme Claude Code peuvent autoriser l'exécution de code sans confirmation, lancer des serveurs MCP non épinglés ou contenir des secrets en clair. deadweight, mon outil open source, les repère et les classe par gravité.
Cadre d'intervention
Dans le cadre habituel, en régie, au forfait ou en consulting, au TJM affiché sur le site. Pas de grille tarifaire ni d'offre packagée : le format se choisit selon la mission.
Ce que je fais, et pour qui
Je travaille sur la sécurité de l'application elle-même : son code, ses dépendances, son front-end, sa configuration. Cela convient aux équipes produit, aux PME et aux agences qui ont une application JavaScript en production, ou sur le point de l'être, et qui veulent un regard de développeur senior.
Ce que je ne fais pas
Pas de test d'intrusion, pas d'audit d'infrastructure ou de réseau, pas de certification ni de conformité (ISO 27001, SOC 2, PCI). Pour cela, je vous oriente vers un cabinet spécialisé.
Ce que je peux montrer
Vingt-cinq ans de développement, et la sécurité a toujours fait partie du métier. Voici quatre choses que je peux décrire ou montrer.
Saint-Gobain Homly-you : deux semaines d'audit du front-end
La mission a commencé par deux semaines d'audit de sécurité du front-end, remis au client. L'application reposait beaucoup sur JavaScript et sur des bibliothèques tierces. J'ai inventorié chacune, évalué sa justification, sa provenance, son périmètre et son mode de chargement, puis rationalisé et optimisé : retirer, remplacer, regrouper. Les constats restent confidentiels.
Voir les réalisationsdeadweight : des contrôles de sécurité, en open source
Mon outil (licence MIT) classe par gravité ce qu'une configuration d'assistant IA laisse faire : règles qui exécutent du code sans confirmation, serveurs MCP non épinglés, téléchargement envoyé dans un shell, caractères unicode cachés, secrets en clair, MCP en http. Mesuré sur 600 dépôts publics : 5 autorisations totales, 2 secrets en clair, 93 autorisations trop larges dans 42 dépôts, 47 serveurs MCP non épinglés dans 26 dépôts.
Voir deadweightVitaPulse : une section sécurité dans chaque scan
VitaPulse, mon SaaS de performance web, ajoute une section Sécurité à chaque scan, en quatre onglets : dix en-têtes HTTP de sécurité classés par gravité (Strict-Transport-Security, Content-Security-Policy, X-Frame-Options et sept autres), le détail TLS (protocole, chiffrement, émetteur et validité du certificat), les versions de logiciels exposées par le serveur, et les audits de sécurité de Lighthouse. Il lit ce que le serveur et la page exposent, pas le code ni les dépendances. Vingt-six vulnérabilités sont documentées publiquement, en cinq langues.
Voir VitaPulseCe site lui-même
Le dépôt est privé, voici donc ce que je peux dire simplement. Les codes de sécurité à usage unique envoyés par e-mail sont générés avec un générateur aléatoire cryptographique, stockés hachés (SHA-256) et comparés en temps constant. Côté mots de passe, c'est bcrypt. Chaque route sensible a sa limite de débit, avec blocage d'adresses IP et de comptes. reCAPTCHA est vérifié côté serveur. Les cookies de session sont durcis et détruits quand les identifiants changent. Une Content Security Policy (Helmet) encadre ce que le navigateur charge. Chaque semaine, un audit des dépendances passe en échec dès qu'une faille de gravité haute apparaît, avec Dependabot en complément.
Une méthode en trois temps
Inventaire
Je recense ce qui compose l'application : bibliothèques, points d'entrée, authentification, secrets, configuration. On ne protège pas ce qu'on n'a pas listé.
Analyse par gravité
Chaque point est évalué et classé par gravité, pour que vous sachiez ce qui se traite cette semaine et ce qui peut attendre.
Correctifs ou plan d'action
Selon votre équipe, j'applique les correctifs dans le code, ou je remets un plan d'action priorisé que votre équipe déroule.
Une application à passer au crible ?
Décrivez-moi l'application et sa stack. Je vous dirai honnêtement si mon périmètre correspond, et sinon vers qui vous tourner.