Audit de code : [Nom du projet]
Remplacez tout ce qui est entre [crochets]. Ne cochez une ligne qu’après avoir vu la preuve vous-même. Tout échec devient un constat numéroté dans le journal final, et l’audit n’est validé que lorsqu’il ne reste aucun constat critique ou élevé ouvert et que le produit est en ligne.
01Périmètre
Fixez précisément ce qui est audité. Un audit de « l’appli » sans commit précis ne peut pas être refait.
- Dépôt: [URL]
- Commit ou tag: [SHA ou tag de version]
- Périmètre convenu: [Version du PRD ou numéro de référence audité]
- Environnement: [URL de production, build du store ou préproduction]
- Auditeur et date: [Nom], [date]
02Couverture des exigences
Le livrable correspond-il à ce qui a été convenu ? Passez les exigences une à une au regard du périmètre figé.
- Chaque exigence Must a des critères d’acceptation
- Chaque exigence Must a un travail terminé qui s’y rattache
- Chaque vérification d’acceptation passe sur le produit en service
- Les exigences modifiées après validation sont signalées, avec l’ancienne et la nouvelle formulation
- Les exigences abandonnées après validation sont consignées comme décisions, pas supprimées
- Les commits et pull requests citent les identifiants d’exigences
03Contrôle d’accès
La plupart des constats graves des petits produits se trouvent ici. Testez en changeant des identifiants et en supprimant des sessions, pas en lisant l’interface.
- Chaque route qui lit ou écrit des données privées vérifie la session
- Les actions d’administration vérifient un rôle ou une permission, pas seulement la connexion
- Modifier un identifiant dans une URL ou une requête ne donne pas accès aux données d’un autre compte
- Les jetons d’API ont une portée limitée et leur révocation est immédiate
- Les liens de réinitialisation, d’invitation et de connexion expirent et ne servent qu’une fois
04Secrets et configuration
Vérifiez l’historique autant que l’état actuel. Une clé supprimée dans un commit ultérieur reste publiée.
- Aucune clé, aucun jeton ni mot de passe dans le dépôt ou son historique
- Les fichiers d’environnement sont exclus du contrôle de version
- Aucun secret serveur n’est exposé au navigateur via une variable publique
- La production et le développement utilisent des identifiants différents
- Les identifiants divulgués ou partagés ont été renouvelés
05Dépendances
Utilisez une base d’avis de sécurité comme npm audit ou OSV et notez les identifiants. Ne vous fiez pas à la mémoire.
- Avis connus vérifiés, identifiants notés pour tout ce qui a été trouvé
- Lockfile versionné et utilisé pour le build
- Paquets non maintenus ou abandonnés signalés
- Scripts d’installation des nouvelles dépendances relus
06Traitement des entrées
Tout ce qu’un utilisateur peut envoyer est non fiable, y compris les en-têtes, les noms de fichiers et le corps des webhooks.
- Les requêtes à la base sont paramétrées, jamais construites par concaténation
- Aucun eval ni exécution dynamique de code à partir d’entrées utilisateur
- Le contenu utilisateur est échappé avant affichage
- Les fichiers envoyés sont contrôlés en type et en taille, et stockés hors de la racine web
- Les requêtes serveur vers des URL fournies par l’utilisateur sont restreintes
- Les formulaires publics ont une limite de débit ou une protection anti-abus
07Parcours d’argent
Tout ce qui est ici passe avant le reste. Un bug qui débite ou crédite deux fois coûte de l’argent chaque heure où il est en ligne.
- Les traitements de paiement et de commande sont idempotents : une nouvelle tentative ne débite pas deux fois
- Les signatures des webhooks sont vérifiées avant de faire confiance à quoi que ce soit
- Prix et montants sont calculés côté serveur, jamais repris du client
- Remboursements, crédits et bons ne peuvent pas être dépensés deux fois en cas de requêtes simultanées
08Fiabilité et exploitation
Ce qui se passe un mauvais jour, et si quelqu’un s’en apercevrait.
- Les erreurs remontent dans un outil de supervision que quelqu’un consulte
- Des sauvegardes existent, et une restauration a réellement été testée
- Les migrations sont appliquées avant la mise en ligne du code qui en dépend
- Les tâches planifiées peuvent s’exécuter deux fois sans dégât
09C’est en ligne
L’audit d’un produit que personne hors de l’équipe ne peut atteindre n’est pas terminé.
- Déployé et accessible à quelqu’un qui ne travaille pas ici
- URL de production ou fiche du store notée
- L’inscription et le parcours principal fonctionnent en production, pas seulement en local
10Journal des constats
Une ligne par vérification échouée. Classez d’abord ce qui coûte de l’argent ou expose des données. Un constat sans preuve est une opinion : retirez-le ou allez chercher la preuve.
Gravité: Critique, Élevée, Moyenne, Faible ou Info
| ID | Gravité | Emplacement | Preuve | Reproduire | Correctif proposé | Statut |
|---|---|---|---|---|---|---|
| F-001 | [Critique] | [chemin/fichier.ts:42] | [Ce qui montre le problème] | [Étapes] | [Modification à faire] | Ouvert |
| F-002 | [Élevée] | [Route ou fichier] | [Ce qui montre le problème] | [Étapes] | [Modification à faire] | Ouvert |
11Verdict
Validé, ou nouvelle itération. Il n’y a pas de validation partielle.
- Résultat: [Validé / Nouvelle itération]
- Constats ouverts: [Nombre par gravité]
- Suite à donner: [Où les correctifs sont suivis]
- Prochain audit: [Date ou déclencheur]