Trouver des bugs

Vérifiez les modifications sur cette branche pour les bugs, les vulnérabilités de sécurité et les problèmes de qualité du code.

Phase 1 : Collecte complète des informations

1. Récupérez le diff COMPLET : git diff $(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')...HEAD
2. Si la sortie est tronquée, lisez chaque fichier modifié individuellement jusqu'à avoir vu toutes les lignes modifiées
3. Listez tous les fichiers modifiés sur cette branche avant de continuer

Phase 2 : Cartographie de la surface d'attaque

Pour chaque fichier modifié, identifiez et listez :

• Toutes les entrées utilisateur (paramètres de requête, en-têtes, corps, composants d'URL)
• Toutes les requêtes de base de données
• Tous les contrôles d'authentification/autorisation
• Toutes les opérations de session/état
• Tous les appels externes
• Toutes les opérations cryptographiques

Phase 3 : Liste de vérification de sécurité (vérifiez CHAQUE élément pour CHAQUE fichier)

• [ ] Injection : SQL, commande, template, injection d'en-tête
• [ ] XSS : Toutes les sorties dans les templates correctement échappées ?
• [ ] Authentification : Contrôles d'authentification sur toutes les opérations protégées ?
• [ ] Autorisation/IDOR : Contrôle d'accès vérifié, pas seulement l'auth ?
• [ ] CSRF : Opérations changeant l'état protégées ?
• [ ] Conditions de concurrence : TOCTOU dans les modèles lecture-puis-écriture ?
• [ ] Session : Fixation, expiration, drapeaux sécurisés ?
• [ ] Cryptographie : Aléatoire sécurisé, algorithmes appropriés, pas de secrets dans les logs ?
• [ ] Divulgation d'informations : Messages d'erreur, logs, attaques par timing ?
• [ ] DoS : Opérations non délimitées, limites de débit manquantes, épuisement des ressources ?
• [ ] Logique métier : Cas limites, violations de machine d'état, débordement numérique ?

Phase 4 : Vérification

Pour chaque problème potentiel :

• Vérifiez s'il est déjà géré ailleurs dans le code modifié
• Recherchez les tests existants couvrant le scénario
• Lisez le contexte environnant pour vérifier que le problème est réel

Phase 5 : Audit pré-conclusion

Avant de finaliser, vous DEVEZ :

1. Lister chaque fichier que vous avez examiné et confirmer que vous l'avez lu complètement
2. Lister chaque élément de la liste de vérification et noter si vous avez trouvé des problèmes ou confirmé qu'il est propre
3. Lister les domaines que vous n'avez PAS pu vérifier complètement et pourquoi
4. Ensuite seulement, fournir vos conclusions finales

Format de sortie

Priorisez : vulnérabilités de sécurité > bugs > qualité du code

Ignorez : les problèmes de style/formatage

Pour chaque problème :

• Fichier:Ligne - Brève description
• Sévérité : Critique/Haute/Moyenne/Basse
• Problème : Ce qui ne va pas
• Preuve : Pourquoi c'est réel (pas déjà corrigé, pas de test existant, etc.)
• Correctif : Suggestion concrète
• Références : OWASP, RFC ou autres normes le cas échéant

Si vous ne trouvez rien de significatif, dites-le - n'inventez pas de problèmes.

Ne faites pas de modifications - rapportez simplement les résultats. Je déciderai ce qu'il faut traiter.