Checklist de sécurité Claude Code pour vérifications rapides d'applications web

Qu'est-ce qu'une vérification de sécurité légère

Une vérification de sécurité légère est une revue rapide (généralement 30–60 minutes) destinée à repérer les problèmes évidents et à fort impact avant mise en production. Ce n’est pas un audit complet. Pensez-y comme une inspection de sécurité : vous parcourez les chemins qui échouent le plus souvent dans les applis réelles et vous cherchez des preuves, pas des suppositions.

Cette checklist Claude Code se concentre sur les zones qui cassent le plus souvent dans les apps web du quotidien :

• Hypothèses d'authentification (comment vous savez qui est l'utilisateur)
• Lacunes d'autorisation (ce qu'il est autorisé à faire)
• Validation des entrées
• Gestion des secrets
• Surfaces d'injection courantes (SQL, exécution de commandes, rendu de templates, redirections, uploads)

Elle ne cherche pas à prouver l'absence de bugs, à modéliser des attaquants complexes, ni à remplacer des tests d'intrusion.

« Constats concrets » signifie que chaque problème que vous consignez comporte des preuves exploitables immédiatement par un développeur. Pour chaque constat, capturez :

• Le(s) fichier(s) et le nom de la fonction/handler exact(s)
• Le comportement risqué en une phrase
• Une étape de repro minimale (requête, payload ou chemin de clic)
• Pourquoi c'est important (impact) et qui peut le déclencher
• Une direction de correction sûre (pas une réécriture complète)

L'IA est un assistant, pas une autorité. Utilisez-la pour chercher, résumer et proposer des tests. Vérifiez ensuite en lisant le code et, si possible, en reproduisant avec une requête réelle. Si le modèle ne peut pas pointer des emplacements et étapes précis, considérez l'affirmation comme non prouvée.

Définir le périmètre en 10 minutes

Une revue rapide ne fonctionne que si vous visez un périmètre restreint. Avant de demander à Claude Code d’examiner quoi que ce soit, décidez ce que vous voulez prouver aujourd’hui et ce que vous n’allez pas vérifier.

Commencez par 1 à 3 parcours utilisateur réels où une erreur coûte de l'argent, expose des données ou accorde des pouvoirs. Bons candidats : login, réinitialisation de mot de passe, checkout, écrans d'édition admin.

Ensuite, nommez les actifs à protéger. Soyez spécifique : comptes utilisateurs, actions de paiement, données personnelles, opérations réservées aux admins.

Écrivez ensuite vos hypothèses de menace en termes simples. Vous défendez-vous contre un utilisateur curieux cliquant partout, un attaquant externe avec des scripts ou un initié avec certains accès ? La réponse change ce qui est « suffisant ».

Enfin, définissez pass/fail afin que la vérification produise des constats concrets, pas des impressions. Des règles simples fonctionnent bien :

• Pass : toute action sensible présente une vérification explicite d'authn et d'authz.
• Fail : tout endpoint qui fait confiance au client pour l'ID utilisateur ou le rôle.
• Pass : les entrées sont validées côté serveur, pas seulement dans l'UI.
• Fail : des secrets apparaissent dans les logs, configs ou dans le code client.

Si vous ne pouvez pas décrire ce qu'est un échec, le périmètre est encore trop flou.

Préparez le contexte que vous fournissez à Claude Code

Une vérification ne marche que si le modèle regarde aux bons endroits. Rassemblez un petit lot de code et de notes pour que la revue produise des preuves, pas des suppositions.

Commencez par partager le chemin critique en sécurité : points d'entrée de requêtes et le code qui décide qui est l'utilisateur et ce qu'il peut faire. Incluez juste assez de code autour pour montrer le flux des données.

Un lot pratique comprend généralement :

• Entrée d'auth : parsing de session/JWT, paramètres des cookies, callbacks de login, middleware d'auth
• Routes + handlers : controllers, méthodes RPC, resolvers GraphQL, handlers de jobs en background
• Couche données : requêtes ORM, helpers SQL bruts, builders de requêtes, migrations pour tables sensibles
• Checks de politique : vérifications de rôles, vérifications de propriété, feature flags, endpoints réservés admin
• Validation : validateurs de schéma de requête, handlers d'upload, code de désérialisation

Ajoutez quelques lignes de notes d'environnement pour expliciter les hypothèses : session vs JWT, où vivent les tokens (cookie ou header), comportement du reverse proxy ou API gateway, workers/queues/cron, et tout endpoint « interne uniquement ».

Avant de chasser des bugs, demandez un inventaire : points d'entrée, endpoints privilégiés, et stores de données touchés. Cela évite de manquer des surfaces.

Accordez-vous aussi sur un format de sortie qui force des constats concrets. Un tableau simple fonctionne bien : Constat, Sévérité, Endpoint/fichier affecté, Preuve (extrait exact ou plage de lignes), Scénario d'exploitation, Suggestion de correction.

Workflow pas à pas pour une revue de 30–60 minutes

Timebox :

• 10 minutes pour s'orienter
• 15–30 minutes pour tracer les flux
• 10 minutes pour rédiger

L'objectif n'est pas la couverture parfaite. C'est un petit ensemble de constats testables.

Gardez l'app ouverte pendant la lecture. Parcourez l'UI et observez quelles requêtes sont envoyées. Les notes doivent pointer vers des endpoints, paramètres et sources de données spécifiques.

Un workflow réalisable en une session :

1. Esquissez les points d'entrée et les frontières de confiance. Notez les routes publiques, routes connectées, routes admin, webhooks, uploads et callbacks tiers. Marquez où les données passent de contrôlées par l'utilisateur à dignes de confiance par le serveur.
2. Pour chaque endpoint important, notez ce qui prouve l'identité et où cela se produit. Si la vérif est dans un « middleware », confirmez que chaque route l'utilise réellement.
3. Faites de même pour l'autorisation. Choisissez une action risquée (voir les données d'autres utilisateurs, modifier des rôles, exporter, supprimer) et suivez la décision de permission jusqu'à la requête base de données.
4. Tracez l'entrée utilisateur jusqu'aux sinks. Suivez un paramètre depuis la requête jusqu'aux requêtes SQL/ORM, rendu de template, exécution shell, fetchs d'URL (SSRF), redirections et chemins de fichiers.
5. Analysez les flux de secrets pendant le tracing. Cherchez des tokens dans les logs, le code client, messages d'erreur, dumps d'environnement et snapshots.

Une habitude utile : pour chaque « ça semble correct », écrivez comment vous le casseriez. Si vous ne pouvez pas décrire une tentative de cassure, vous ne l'avez probablement pas vérifié.

Contrôles d'authn : prouver qui est l'utilisateur

L'authentification, c'est l'endroit où l'app décide « cette requête appartient à cette personne ». Une vérification rapide ne consiste pas à lire chaque ligne. C'est trouver l'endroit où l'identité est établie, puis vérifier les raccourcis et chemins d'échec.

Localisez la frontière de confiance : où l'identité est-elle d'abord créée ou acceptée ? Ça peut être un cookie de session, un token JWT bearer, une clé API, ou du mTLS en périphérie. Demandez à Claude Code de pointer le fichier et la fonction exacts qui transforment « anonyme » en un id utilisateur, et de lister chaque autre chemin qui peut faire la même chose.

Vérifications d'authn à parcourir :

• Identifier tous les points d'entrée d'auth (login web, tokens API, auth mobile, auth service interne) et confirmer qu'ils convergent vers un modèle d'identité cohérent.
• Vérifier login et reset de mot de passe pour limites de débit, verrouillages, et énumération d'utilisateurs (messages d'erreur ou timing différents pour comptes existants/non existants).
• Inspecter sessions et cookies : HttpOnly, Secure, SameSite, expiry, rotation au login et lors d'un changement de privilège, et invalidation du logout (côté serveur, pas seulement « supprimer cookie »).
• Revoir MFA et recovery pour s'assurer que le chemin de récupération n'est pas plus faible que la MFA (par exemple reset par email seul qui contourne la MFA).
• Revoir le logging des échecs d'auth : utile pour l'op, mais ne pas divulguer d'indices utiles aux attaquants (pas de « l'utilisateur existe » ni de dumps de tokens).

Exemple pratique : si les emails de reset renvoient « compte introuvable », c'est un problème d'énumération. Même avec un message générique, des différences de timing peuvent fuir la même information, donc vérifiez aussi les temps de réponse.

Contrôles d'authz : prouver que l'utilisateur est autorisé

L'autorisation est la question qui cause le plus de dégâts quand elle est fausse : « Cet utilisateur peut-il faire cette action sur cette ressource précise ? » Une vérification rapide doit chercher à casser cette hypothèse volontairement.

Écrivez les rôles et permissions en langage simple. Gardez-le humain :

• Le propriétaire peut inviter des membres
• Un membre peut modifier son propre profil
• Le support peut voir les détails de facturation mais pas changer le plan
• L'admin peut supprimer des projets

Puis vérifiez que chaque action sensible applique l'authz côté serveur, pas seulement dans l'UI. Les boutons peuvent être cachés, les routes bloquées côté client, mais un attaquant peut toujours appeler l'API directement.

Un scan rapide qui trouve souvent des problèmes :

• Trouver les endpoints/mutations qui créent, suppriment, exportent, changent des rôles ou accèdent à la facturation
• Pour chacun, localiser la vérification de permission côté serveur (pas le frontend)
• Chercher les IDs contrôlées par l'utilisateur (projectId, userId, orgId) et confirmer les checks de propriété
• Confirmer que les chemins admin-only échouent fermé si le rôle manque
• Vérifier les frontières de tenant : orgId/accountId doit venir du contexte de session, pas seulement de l'entrée requête

L'odeur classique d'IDOR : une requête comme GET /projects/{id} où {id} est contrôlé par l'utilisateur et le serveur le charge sans vérifier qu'il appartient à l'utilisateur ou au tenant courant.

Un prompt qui force une vraie réponse :

« Pour cet endpoint, montrez le code exact qui décide l'accès, et listez les conditions spécifiques qui permettraient à un utilisateur d'un autre orgId d'y accéder. Si aucune, expliquez pourquoi en donnant fichiers et noms de fonctions. »

Validation des entrées : refouler les mauvaises données dès l'entrée

La plupart des bugs rapides commencent par une lacune : l'app accepte des entrées que le développeur n'attendait pas. Traitez « entrée » comme tout ce qu'un utilisateur ou un autre système peut influencer, même si ça semble inoffensif.

Commencez par nommer les entrées pour l'endpoint que vous vérifiez :

• Valeurs de query et de path
• Champs du body (y compris JSON imbriqué)
• Headers (auth, content-type, forwarded IP)
• Cookies
• Uploads de fichiers (nom, taille, type, métadonnées)

La validation doit se produire près du point d'entrée, pas profondément dans la logique métier. Vérifiez le basique : type (string vs number), longueur max, requis vs optionnel, et format (email, UUID, date).

Pour des valeurs connues comme rôles, statuts ou directions de tri, préférez une allowlist. C'est plus difficile à contourner qu'« on bloque quelques valeurs ».

Vérifiez aussi le traitement des erreurs. Si l'app rejette une entrée, n'échoez pas la valeur brute dans la réponse, les logs ou l'UI. C'est comme ça que de petits bugs de validation deviennent des fuites de données ou des aides pour l'injection.

Un mini-plan « mauvaise entrée » pour endpoints risqués (login, search, upload, actions admin) :

• Chaînes trop longues (10 000+ caractères)
• Mauvais types (array au lieu de string)
• Valeurs d'enum inattendues
• Caractères spéciaux qui changent le sens
• Valeurs vides pour des champs requis

Exemple : un paramètre de tri qui accepte n'importe quelle chaîne peut devenir un fragment SQL plus loin. Une allowlist comme "date" ou "price" évite ce type d'erreur tôt.

Surfaces d'injection communes à scanner rapidement

La plupart des revues rapides trouvent des problèmes aux mêmes endroits : partout où l'entrée utilisateur est interprétée comme du code, une requête, un chemin ou une URL. Ici, chassez les moments où « l'entrée traverse une frontière de confiance ».

Tracez les données depuis les points d'entrée (query params, headers, cookies, uploads, formulaires admin) jusqu'à leurs usages.

Cibles de scan rapide

Cherchez ces motifs et exigez un site d'appel concret et un exemple de payload pour chacun :

• Injection SQL : requêtes construites en concaténant des chaînes, ORDER BY dynamique, et builders IN (...) qui joignent des valeurs utilisateurs
• XSS : rendu HTML, templates, previews markdown, éditeurs rich text où « on sanitize plus tard » est présumé
• Injection de commande : appels shell autour du traitement d'images, outils PDF, backups, ou étapes « convert » qui transmettent des flags contrôlés par l'utilisateur
• SSRF : fetchs d'URL pour webhooks, preview de lien, import depuis URL, ou checks internes qui acceptent une URL utilisateur
• Traversée de chemin : endpoints de téléchargement de fichiers, extraction de zip, pipelines d'upload qui lisent ensuite des fichiers par nom

Surveillez aussi la désérialisation et l'injection de template. Tout ce qui parse du JSON, YAML ou des chaînes templatisées fournies par l'utilisateur peut cacher un comportement risqué, surtout si ça supporte des types personnalisés, des expressions ou du rendu côté serveur.

Si une fonctionnalité accepte une URL, un nom de fichier ou du texte formaté, supposez qu'elle peut être abusée jusqu'à preuve du contraire avec des chemins et tests concrets.

Gestion des secrets : trouver fuites et stockage faible

Les problèmes de secrets sont souvent bruyants une fois que vous savez où regarder. Concentrez-vous sur où les secrets vivent et où ils peuvent être copiés accidentellement.

Endroits courants où les secrets apparaissent :

• Variables d'environnement et fichiers de config d'app
• Sorties CI et logs de build (y compris logs de déploiement échoués)
• Bundles client et builds mobiles (tout ce qui est livré aux utilisateurs)
• Endpoints de debug, pages health, outils admin
• Pages d'erreur, traces de stack, et événements analytiques

Ensuite, forcez une réponse concrète : si un secret est exposé aujourd'hui, que se passe-t-il ensuite ? Un bon système a un chemin de rotation (nouvelle clé émise), révocation (ancienne clé désactivée), et moyen de redéployer rapidement. Si la réponse est « on le changerait plus tard », considérez cela comme un constat.

Le principe du moindre privilège est aussi une victoire rapide. Les incidents empirent parce que les clés sont sur-puissantes. Cherchez des utilisateurs DB qui peuvent dropper des tables, des tokens tiers qui peuvent gérer des comptes, ou des API keys partagées entre environnements. Préférez une clé par service, par environnement, avec le minimum de permissions.

Prompts rapides à coller dans Claude Code :

• « Cherche les tokens hardcodés, mots de passe et clés privées. Liste les chemins de fichiers exacts et les motifs de chaîne trouvés. »
• « Trouve tout code qui logge headers, cookies, env vars ou objets d'erreur complets. Montre les lignes de log et quels champs sensibles pourraient apparaître. »
• « Vérifie si des secrets peuvent finir dans des snapshots, exports ou artefacts de build. Identifie ce qui est capturé et où c'est stocké. »

Enfin, confirmez des garde-fous : bloquer les secrets du contrôle de source (pre-commit/CI), et vous assurer que les backups ou snapshots n'incluent pas de credentials en clair. Si la plateforme supporte snapshots et rollback, vérifiez que les secrets sont injectés à l'exécution, pas incorporés dans des images sauvegardées.

Prompts qui forcent des constats concrets (patterns à copier-coller)

Les prompts vagues donnent des réponses vagues. Forcez le modèle à s'engager sur des preuves : emplacements exacts, un trace que vous pouvez suivre, une repro exécutable, et ce qui rendrait l'affirmation fausse.

Utilisez un pattern à la fois, puis demandez une révision après confirmation ou rejet d'un détail.

• Preuve au niveau fichier : « Cherche le repo pour auth, sessions, tokens et middleware. Nomme les fichiers exacts, fonctions et plages de lignes impliquées. Cite les extraits pertinents. Si tu ne peux pas pointer le code, dis ‘no evidence found’. »
• Tracer de l'entrée au sink : « Choisis une entrée contrôlée par l'utilisateur (header, query, body, cookie). Montre le flux de données étape par étape depuis le point d'entrée jusqu'à son usage (SQL, HTML, shell, template, redirect, chemin fichier). Liste chaque fonction de la chaîne. »
• Étapes de repro : « Donne une repro minimale avec curl (méthode, forme de l'URL, headers, body). Inclue le code de statut attendu et un exemple de réponse succès/échec. Indique les hypothèses (rôles, état d'auth). »
• Contrôle des faux positifs : « Qu'est-ce qui infirmerait ce constat ? Liste 2–3 vérifications : flags de config, ordre des middlewares, validation allowlist, requêtes paramétrées, échappement du framework. Si l'un est présent, explique pourquoi le risque change. »
• Plus petite correction sûre + test : « Propose le plus petit changement qui bloque le problème sans casser les cas valides. Puis écris un test à ajouter (nom, intention, inputs, résultat attendu). Si il y a des compromis, détaillez-les. »

Si la sortie reste floue, recadrez :

« Réponds uniquement avec : chemin de fichier, nom de fonction, ligne risquée, et impact en une phrase. »

Un exemple réaliste : transformer une intuition en problème vérifié

Les endpoints de mise à jour de profil cachent souvent des erreurs de contrôle d'accès. Voici un petit cas à traiter avec cette checklist.

Scénario : un endpoint API met à jour un profil utilisateur :

PATCH /api/profile?accountId=123 avec un JSON comme { "displayName": "Sam" }.

Vous demandez à Claude Code de trouver le handler, tracer comment accountId est utilisé, et prouver si le serveur applique la propriété.

Ce qui apparaît souvent :

• Authn : la requête exige une session ou token, donc semble protégée.
• Authz : le handler fait confiance à accountId depuis la query string et met à jour ce compte sans vérifier qu'il correspond à l'utilisateur connecté.
• Validation : displayName est trimé, mais accountId n'est pas validé en entier.
• Surface d'injection : le SQL est construit par concaténation comme "... WHERE account_id=" + accountId.

Un bon rapport est concret :

• Sévérité : Élevée (IDOR + possible injection SQL)
• Preuve : une requête avec une session valide modifie un autre utilisateur quand accountId est changé ; le SQL est construit depuis une entrée non fiable
• Correction : ignorer accountId venant du client, utiliser l'id du compte authentifié côté serveur ; paramétrer la requête
• Test : tenter de mettre à jour un autre compte et attendre 403 ; rejeter un accountId non numérique

Après correction, re-vérifiez rapidement :

• Essayez la même requête avec un autre accountId et confirmez l'échec.
• Confirmez dans les logs que le serveur utilise l'id authentifié, pas le paramètre query.
• Confirmez que la requête utilise des placeholders/params, pas de concaténation de chaînes.
• Lancez un test négatif pour une entrée malformée (lettres, très grand nombre).

Pièges courants qui font rater de vrais problèmes

La façon la plus rapide de manquer une vulnérabilité est de faire confiance à ce que l'UI semble imposer. Un bouton caché ou désactivé n'est pas une vérification de permission. Si le serveur accepte quand même la requête, n'importe qui peut la rejouer avec un autre ID, rôle ou appel direct à l'API.

Un autre échec fréquent est une demande vague. « Faire une revue de sécurité » donne souvent un rapport générique. Une vérification rapide a besoin d'un périmètre serré (quels endpoints, quels rôles, quelles données) et d'un format de sortie strict (nom de fichier, fonction, ligne risquée, repro minimale).

La même règle vaut pour la sortie IA : n'acceptez pas d'affirmations sans pointeurs. Si un constat n'inclut pas un emplacement de code concret et une démarche pas à pas pour le déclencher, considérez-le non prouvé.

Moyens rapides pour que les spot-checks se trompent

Ces pièges reviennent souvent :

• Partir du principe « admin-only » parce que c'est une page admin, au lieu de vérifier que le serveur l'applique
• Demander des résultats larges plutôt que « montre-moi la requête exacte qui contourne X »
• Accepter « possible SQL injection » sans pointer la construction de la requête et le chemin d'entrée
• Sauter des points d'entrée moins évidents comme webhooks, jobs planifiés, outils d'import, et actions admin internes
• Corriger des symptômes (ajout de filtres ou regex) alors que la cause racine est une validation manquante ou une autorisation absente

Si vous ajoutez sans cesse des filtres après chaque nouveau cas, marquez une pause. La correction est souvent plus simple et plus en amont : valider aux frontières et centraliser les vérifications d'autorisation pour que tous les chemins y passent.

Vérifications rapides à faire avant déploiement

Cela ne remplace pas une revue complète, mais ça attrape des erreurs glissées quand tout le monde est fatigué. Gardez-les focalisées sur ce que vous pouvez prouver vite : une requête à envoyer, une page à charger, une ligne de log à trouver.

Cinq spot-checks rapides qui rapportent souvent :

• Friction d'authn : tentez 10 logins incorrects de suite. Voyez-vous des limites de débit, des verrouillages, ou au moins un ralentissement ? Peut-on déduire si un email existe via les messages d'erreur ou le timing ?
• Authz par swap d'ID : prenez une ressource réelle (commande, facture, profil). Changez l'ID dans l'URL, le body JSON, ou les variables GraphQL. Récupérez-vous des données qui ne sont pas à vous, même des métadonnées ?
• Garde-fous input : pour les champs clés (email, nom, recherche, upload), testez des chaînes très longues, Unicode étrange, et types inattendus (nombre au lieu de chaîne). Imposer des limites de longueur et des allowlists là où c'est important ?
• Exposition de secrets : cherchez dans les logs récents et les bundles clients des tokens, clés API, JWT, ou "Authorization: Bearer". Vérifiez aussi les pages d'erreur. « C'était seulement en staging » devient souvent « c'est parti en prod ».
• Surfaces d'injection : cherchez de la concaténation de chaînes dans SQL, filtres, rendu de templates, commandes shell, ou URLs de redirection. Si une entrée atteint l'un de ces points sans validation forte, supposez le risque jusqu'à preuve du contraire.

Notez les 3 corrections prioritaires que vous pouvez livrer cette semaine, pas une liste de souhaits. Exemple : (1) ajouter du rate limiting au login et reset, (2) appliquer des vérifications de propriété côté serveur sur l'endpoint “get by id”, (3) limiter la longueur d'entrée et rejeter les caractères inattendus pour le champ recherche.

Étapes suivantes : intégrer cette checklist à votre processus de build

Une vérification n'est utile que si ses résultats influencent ce que vous livrez. Traitez cette checklist comme une petite étape reproductible de build, pas une mission de sauvetage ponctuelle.

Transformez chaque constat en ticket clair :

• Fix : ce qui changera dans le code ou la config
• Test : comment prouver que c'est corrigé (une requête, un test unitaire, une étape QA)
• Propriétaire : une personne responsable
• Date cible : prochaine release ou un jour précis
• Preuve : fichier/endpoint et la requête/payload exact qui a montré le problème

Choisissez une cadence adaptée au risque et à la taille de l'équipe. Pour beaucoup, chaque release est idéale. Si les releases sont fréquentes, faites une revue de 30–60 minutes mensuelle et une vérif plus courte avant mise en production.

Facilitez la répétition en créant un pack de prompts réutilisables et un modèle de checklist. Gardez les prompts focalisés sur des sorties concrètes : montre la route, la garde, la requête qui échoue, et le comportement attendu. Stockez le pack là où l'équipe travaille déjà pour qu'il ne soit pas oublié.

Si vous construisez des apps via chat, intégrez la checklist dès la planification. Ajoutez une courte note d'« hypothèses de sécurité » pour authn/authz, inputs et secrets, puis lancez le spot-check dès la première version fonctionnelle.

Les plateformes comme Koder.ai (koder.ai) s'intègrent bien à cette habitude car elles permettent d'itérer vite tout en conservant des checkpoints de revue. Utiliser snapshots et rollback autour de changements risqués facilite la livraison des corrections de sécurité sans rester bloqué quand un changement casse un comportement.