Auditer la sécurité de ce que tu viens de coder
Cinq passes ciblées, dans l'ordre, plutôt qu'un « vérifie la sécurité » qui ne trouve rien.
« Vérifie la sécurité de mon application » ne trouve presque rien. Le périmètre est trop large, le modèle survole, et rend trois généralités rassurantes. Cinq passes ciblées, chacune avec une question précise, trouvent des choses réelles.
L'ordre compte : on commence par ce qui est exploitable sans effort.
Avant de commencer
- Une application dont tu as le code
- Claude Code installé
- Une heure, à répartir sur les cinq passes
1Les secrets
Le plus fréquent, et le plus facile à exploiter.
Cherche dans tout le depot des secrets en dur : cles d'API, mots de passe,
jetons, chaines de connexion. Regarde aussi les fichiers de configuration,
les tests, les commentaires et les exemples. Pour chacun : fichier, ligne,
et s'il est encore valide ou visiblement revoque.
Puis, ce que tout le monde oublie :
Verifie si un de ces secrets est present dans l'historique git, meme s'il a
ete supprime depuis.
Un secret commité est un secret brûlé
Le retirer du code ne suffit pas : il reste dans l'historique. La seule réponse correcte est de le révoquer et d'en générer un nouveau.
2Les entrées non validées
Trace chaque donnee venant de l'exterieur (parametres de requete, corps JSON,
en-tetes, formulaires, fichiers televerses) jusqu'a son usage. Signale les cas
ou elle atteint sans validation : une requete base de donnees, une commande
shell, une lecture de fichier, ou du HTML rendu.
Pour chacun : le chemin complet de la donnee, et ce qu'un attaquant en ferait.
La dernière phrase est importante. Sans elle, on obtient une liste d'endroits « à surveiller » ; avec elle, on obtient des scénarios qu'on peut juger.
3Le contrôle d'accès
C'est la faille la plus coûteuse, et la moins détectable par un outil automatique : rien n'est cassé, la mauvaise personne accède juste à la bonne donnée.
Liste toutes les routes de l'application dans un tableau : chemin, methode,
qui devrait pouvoir l'appeler, et ce que le code verifie reellement.
Signale les lignes ou les deux dernieres colonnes ne coincident pas.
Puis le cas classique :
Cherche les endpoints qui prennent un identifiant en parametre et renvoient
une ressource sans verifier qu'elle appartient a l'utilisateur connecte.
4Les dépendances et la configuration
npm audit --omit=dev
Puis la lecture que l'outil ne fait pas :
Parmi ces vulnerabilites, lesquelles sont reellement atteignables dans notre
code ? Pour chacune, montre le chemin d'appel, ou dis qu'il n'y en a pas.
Beaucoup d'alertes concernent du code jamais exécuté. Trier évite de passer une journée sur des mises à jour sans effet.
Côté configuration :
Verifie : CORS trop permissif, cookies sans HttpOnly ou SameSite, mode debug
actif, messages d'erreur qui renvoient une trace au client, en-tetes de
securite absents.
5Faire relire par un regard neuf
Les quatre passes précédentes ont eu lieu dans une conversation qui connaît le contexte, et qui a donc les mêmes angles morts que toi.
Lance un agent independant qui relit uniquement le diff, sans savoir ce qu'on
cherchait a faire. Consigne : trouver ce qui peut etre exploite. Qu'il rende
un tableau fichier, ligne, scenario d'attaque, gravite.
S'il ne trouve rien, qu'il le dise au lieu d'inventer.
Autoriser le vide
La dernière phrase réduit beaucoup les faux positifs. Un relecteur qui n'a pas le droit de ne rien trouver trouvera quelque chose.
Ce que cet audit ne remplace pas
Sois clair sur la portée. Cette méthode trouve des défauts de code courants. Elle ne remplace pas :
- un test d'intrusion sur l'application déployée ;
- une revue d'architecture (segmentation, secrets en production, sauvegardes) ;
- une analyse de la chaîne d'approvisionnement (qui publie tes dépendances) ;
- une revue de conformité, si tu traites des données personnelles.
Ne teste que ce qui t'appartient
Ces prompts s'appliquent à ton code et à tes environnements. Sur un système tiers, il faut une autorisation écrite.
Le tableau de bord
| Passe | Question | Signal d'alarme |
|---|---|---|
| Secrets | Y a-t-il une clé dans le dépôt ou l'historique ? | N'importe quelle occurrence |
| Entrées | Une donnée externe atteint-elle une requête ou un shell ? | Concaténation de chaîne |
| Accès | Qui peut appeler quoi, réellement ? | Route sans vérification de propriété |
| Dépendances | Les alertes sont-elles atteignables ? | Chemin d'appel existant |
| Regard neuf | Que trouve quelqu'un sans contexte ? | Tout ce que les quatre passes ont raté |
Tu as d’autres ressources comme ça ?
Ce que tu viens de lire est entièrement gratuit. Une nouvelle ressource part chaque semaine dans la newsletter : guides, modèles à copier et liens triés, sans compte à créer.
Me contacter
Une question, un projet, une envie de collaborer ? Écris-moi.
Cette page est en accès libre, n’hésite pas à la partager.