Skills & Plugins
pour Claude Code

Audite toute l'authentification de mon application. Objectif : le jeton de session ne doit jamais être accessible par du JavaScript côté client.

1. Trouve tout endroit où un token, un JWT ou un identifiant de session est stocké dans localStorage ou sessionStorage, et supprime-le.
2. Migre la session vers un cookie httpOnly + secure + SameSite=Strict.
3. Mets une durée de vie courte sur le token d'accès, avec un refresh token rotatif stocké côté serveur et révocable.
4. Assure-toi qu'aucun token n'apparaît dans une URL, un log, ou une réponse d'API inutile.

Liste chaque fichier que tu modifies, montre-moi le diff, et explique en une phrase le risque que chaque changement corrige.

Passe en revue toutes les vérifications de rôle, de permission et de propriété dans mon application.

Règle absolue : aucune décision d'autorisation (isAdmin, role, plan, owner_id, is_premium…) ne doit dépendre d'une donnée envoyée par le client. Tout doit être re-vérifié côté serveur, à chaque requête, à partir de la session authentifiée.

1. Liste toutes les routes et actions sensibles de mon app.
2. Pour chacune, dis-moi si l'autorisation est vérifiée côté serveur — et si non, corrige.
3. Mets en place un middleware d'autorisation centralisé (deny par défaut) et applique-le partout.
4. Vérifie aussi la propriété des ressources : un utilisateur ne doit jamais pouvoir lire ou modifier l'objet d'un autre en changeant un ID.

Donne-moi la liste des routes qui n'étaient pas protégées avant ta correction.

Ajoute un rate limiting sur toutes les routes sensibles de mon application.

1. Couvre au minimum : connexion, inscription, réinitialisation de mot de passe, renvoi d'email, et toute route API coûteuse.
2. Limite à la fois par adresse IP et par compte visé, pour éviter qu'on cible un seul utilisateur depuis plusieurs IP.
3. Ajoute un délai progressif (backoff) puis un verrouillage temporaire du compte après plusieurs échecs consécutifs, avec un message générique — ne révèle jamais si c'est l'email ou le mot de passe qui est faux.
4. Journalise les tentatives échouées (horodatage, IP, compte visé) pour pouvoir détecter une attaque.

Donne-moi la configuration exacte et les seuils que tu recommandes, et explique pourquoi.

Ajoute une vérification d'email obligatoire et la double authentification à mon application.

Vérification d'email :
1. À l'inscription, envoie un lien de vérification avec un token à usage unique, aléatoire et expirant sous 24h.
2. Tant que l'email n'est pas vérifié, le compte n'a accès à aucune action ni donnée sensible.
3. Applique un rate limit sur le renvoi de l'email de vérification.

Double authentification (2FA) :
4. Ajoute la 2FA par TOTP, compatible avec Google Authenticator / Authy (QR code à scanner).
5. Génère des codes de secours à usage unique, affichés une seule fois et stockés hachés.
6. Rends la 2FA obligatoire pour tout compte administrateur.

Montre-moi les fichiers modifiés et le parcours utilisateur complet.

Renforce toute la politique de mots de passe de mon application.

1. Hachage : utilise argon2id (ou bcrypt avec un coût adapté). Jamais de mot de passe en clair, jamais de MD5 ni de SHA-1.
2. Longueur minimale de 12 caractères, sans règle de complexité absurde — la longueur prime.
3. Refuse les mots de passe déjà compromis : interroge l'API HaveIBeenPwned en k-anonymity (on envoie uniquement les 5 premiers caractères du hash SHA-1, jamais le mot de passe). Si le mot de passe apparaît dans une fuite connue, refuse-le avec un message clair.
4. Refuse aussi les mots de passe qui contiennent l'email ou le nom du service.
5. Applique tout ça à l'inscription ET au changement de mot de passe.

Implémente-le, et montre-moi comment tester que ça fonctionne.

Fais un audit de sécurité complet de mon application, comme le ferait un auditeur externe.

Vérifie au minimum : l'authentification et la gestion de session, l'autorisation sur chaque route, la validation des entrées utilisateur, les injections (SQL, NoSQL, commandes), le XSS, le CSRF, l'exposition de données sensibles dans les réponses d'API, les secrets et clés d'API en dur dans le code, les dépendances vulnérables, les en-têtes de sécurité HTTP, et la configuration CORS.

Pour chaque problème trouvé, donne-moi : le fichier concerné, le niveau de gravité (critique / élevé / moyen / faible), ce qu'un attaquant pourrait faire, et le correctif. Classe par gravité. Ne corrige rien tant que je n'ai pas validé.