Kit d’audit automatisé basé sur les recommandations de l’ANSSI pour la sécurité des applications web côté navigateur. Utilise Claude Code pour analyser statiquement un projet et vérifier la conformité aux 71 recommandations du référentiel.
- Claude Code installé et configuré
Ouvrir Claude Code depuis ce répertoire :
cd /chemin/vers/audit-secu
claudePuis exécuter les 3 commandes dans l’ordre :
/init-audit mon-app /home/user/dev/mon-app
/scan-projet mon-app /home/user/dev/mon-app
/audit-securite mon-app /home/user/dev/mon-app
Les 3 commandes sont des slash commands Claude Code (définies dans .claude/commands/).
Elles s’exécutent dans le chat Claude Code, pas dans un terminal.
Chaque commande prend 2 arguments séparés par un espace :
| Argument | Description | Exemple |
|---|---|---|
<nom-audit> |
Nom choisi pour cet audit (sera le nom du dossier de résultats) | mon-app |
<chemin-projet> |
Chemin absolu vers le projet à auditer | /home/user/dev/mon-app |
Les deux arguments doivent être identiques entre les 3 commandes pour que chaque étape retrouve le contexte de la précédente.
/init-audit <nom-audit> <chemin-projet>
Ce qu’elle fait : Crée un dossier <nom-audit>/ à la racine de ce répertoire en copiant le template .audit-securite/. Ce dossier contiendra tous les résultats de l’audit.
Résultat : Un dossier <nom-audit>/ avec suivi.md et 71 fiches de recommandations vierges.
Prérequis : Aucun.
/scan-projet <nom-audit> <chemin-projet>
Ce qu’elle fait : Analyse le projet cible en lecture seule et produit un rapport scan-projet.md dans le dossier d’audit. Le scan couvre :
- Structure et arborescence du projet
- Stack technique (langages, frameworks, serveur, BDD, CI/CD)
- Configuration TLS/HTTPS et en-têtes de sécurité HTTP
- Cookies, sessions, stockage côté client
- Pratiques JavaScript à risque (innerHTML, eval, document.write, etc.)
- CORS, XHR/Fetch, CSRF
- Intégrité des ressources et composants tiers
- Déploiement et environnements
Résultat : Fichier <nom-audit>/scan-projet.md.
Prérequis : Avoir exécuté /init-audit avec le même <nom-audit>.
/audit-securite <nom-audit> <chemin-projet>
Ce qu’elle fait : Vérifie chaque recommandation ANSSI en cherchant les preuves dans le code du projet. Pour chacune des 71 recommandations :
- Lit la fiche de recommandation pour comprendre ce qui doit être vérifié
- Cherche les preuves dans le projet (code, config, infra)
- Établit un constat avec statut, description et fichiers preuves
- Met à jour la fiche
RNN.mdet le tableausuivi.md
Résultat : Les 71 fiches RNN.md complétées + suivi.md avec la synthèse globale.
Prérequis : Avoir exécuté /init-audit et /scan-projet avec le même <nom-audit>. Le scan n’est pas obligatoire mais il accélère significativement l’audit en fournissant le contexte du projet.
/init-audit preliq /home/negus/dev/newwinpaie
/scan-projet preliq /home/negus/dev/newwinpaie
/audit-securite preliq /home/negus/dev/newwinpaie
Après exécution, la structure générée :
preliq/
├── suivi.md # Tableau de suivi avec statuts et synthèse
├── scan-projet.md # Rapport de scan du projet
└── recommandations/
├── 01-TLS-et-transport-securise/
│ ├── R01.md # Fiche avec constat, statut et preuves
│ ├── R02.md
│ └── R03.md
├── 02-Composition-des-pages-et-DOM/
│ ├── R04.md
│ ├── R05.md
│ └── R06.md
├── ...
└── 21-Composants-logiciels-tiers/
├── R61.md
├── R62.md
└── R63.md
.
├── .audit-securite/ # Template de base (ne pas modifier)
│ ├── suivi.md # Tableau de suivi vierge
│ └── recommandations/ # 71 fiches de recommandations
│ ├── 01-TLS-et-transport-securise/
│ ├── 02-Composition-des-pages-et-DOM/
│ ├── ...
│ └── 21-Composants-logiciels-tiers/
├── .claude/commands/ # Définitions des 3 commandes
│ ├── init-audit.md
│ ├── scan-projet.md
│ └── audit-securite.md
├── <nom-audit>/ # Dossiers d’audit générés (un par projet)
└── README.md
| # | Catégorie | Nb |
|---|---|---|
| 01 | TLS et transport sécurisé | 3 |
| 02 | Composition des pages et DOM | 3 |
| 03 | Échappement et validation des contenus | 4 |
| 04 | Intégrité des ressources | 3 |
| 05 | Content Security Policy (CSP) | 8 |
| 06 | Politique Referer | 2 |
| 07 | Stockage local | 5 |
| 08 | Cookies | 8 |
| 09 | XMLHttpRequest (XHR) et Fetch | 7 |
| 10 | CORS | 2 |
| 11 | Isolation des services | 4 |
| 12 | API Fetch | 1 |
| 13 | Fenêtres et navigation | 2 |
| 14 | Mode strict JavaScript | 1 |
| 15 | Web Workers | 2 |
| 16 | API de Message (postMessage) | 1 |
| 17 | Iframes et sandboxing | 4 |
| 18 | Communication inter-contextes | 4 |
| 19 | Pratiques obsolètes et dangereuses | 2 |
| 20 | Déploiement et configuration | 2 |
| 21 | Composants logiciels tiers | 3 |
| Total | 71 |
| Emoji | Statut | Signification |
|---|---|---|
| ✅ | Conforme | Recommandation pleinement respectée |
| Partiel | Partiellement respectée, des écarts subsistent | |
| ❌ | Non conforme | Non respectée ou absente |
| 🔍 | À vérifier | Nécessite une vérification manuelle ou runtime |
Chaque fiche RNN.md contient l’explication de la recommandation (template) puis, après audit, le constat :
# RNN — Intitulé de la recommandation
**Explication** : Description technique de la recommandation
**Statut** : ✅ Conforme | ⚠️ Partiel | ❌ Non conforme | 🔍 À vérifier
**Vérification** : Effectuée le YYYY-MM-DD
**Constat** : Description factuelle de ce qui a été trouvé
**Preuves/Fichiers** :
- `chemin/fichier:lignes` — descriptionLes variantes RNN-.md (niveau dégradé) et RNN+.md (niveau renforcé) couvrent différents niveaux d’exigence pour une même recommandation.
- L’audit est statique : il analyse le code source, les fichiers de configuration et l’infrastructure-as-code. Il ne teste pas le comportement runtime de l’application (en-têtes HTTP réels, comportement TLS, etc.).
- Les recommandations marquées "À vérifier" nécessitent un test manuel ou un accès à l’application en fonctionnement.
- Le projet cible n’est jamais modifié — l’audit est en lecture seule.